[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-v6ops-802-16-deployment-scenarios

Network Working Group                                          M-K. Shin
Internet-Draft                                                      ETRI
Expires: August 27, 2006                                        Y-H. Han
                                                             Samsung AIT
                                                       February 23, 2006


  ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks
            draft-shin-v6ops-802-16-deployment-scenarios-00

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 August 27, 2006.

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.



Shin & Han               Expires August 27, 2006                [Page 1]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Wireless Broadband Access Network Technologies - IEEE
       802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  IEEE 802.16 Networks Elements  . . . . . . . . . . . . . .  4
     2.2.  Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . .  5
       2.2.1.  Scenario A . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.2.  Scenario B . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Scenario C . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.4.  Scenario D . . . . . . . . . . . . . . . . . . . . . . 11
     2.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13
     2.4.  IPv6 Mobility  . . . . . . . . . . . . . . . . . . . . . . 13
     2.5.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.6.  IPv6 Security  . . . . . . . . . . . . . . . . . . . . . . 14
     2.7.  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



























Shin & Han               Expires August 27, 2006                [Page 2]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


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 on broadband wireless access standards 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] addresses
   fixed wireless applications only, the IEEE 802.16(e) standard
   [IEEE802.16e] will serve the needs of fixed, nomadic, and fully
   mobile networks.  It adds mobility support to the original standard
   so that mobile subscriber stations can move during services.
   Currently, the standardization of IEEE 802.16e is underway, 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 specifications.

   As the deployment of wireless broadband access network progresses,
   users will be connected to IPv6 networks.  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] follows the structure and common terminology of the draft.












Shin & Han               Expires August 27, 2006                [Page 3]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


2.  Wireless Broadband Access Network Technologies - IEEE 802.16

   This section describes the infrastructure that exists today in IEEE
   802.16 networks providing wireless broadband services to the
   customer.  It also describes IPv6 deployment options in these IEEE
   802.16 networks.

2.1.  IEEE 802.16 Networks Elements

   The IEEE 802.11 access network (WLAN) has driven the revolution of
   wireless communication but the more people use it the more its
   limitations like short range or lack of mobility support were
   revealed.  Compared with such IEEE 802.11 network, IEEE 802.16
   supports enhanced features like wider range 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 network:

   SS: Subscriber Station.  A general equipment set providing
   connectivity between subscriber equipment and a BS.

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

   BS: Base Station.  A generalized equipment set providing
   connectivity, management and control of MS connections.  A
   unidirectional mapping between BS and MS medium access control (MAC)
   peers for the purpose of transporting a service flow's traffic.
   Connections are identified by a connection identifier (CID).  All
   traffic is carried on a connection.

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













Shin & Han               Expires August 27, 2006                [Page 4]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


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

       +-----+            +-----+     +------+   +--------+
       | MSs |--(802.16)--| BS  |-----+Access+---+ Edge   |    ISP
       +-----+            +-----+     |Router|   | Router +==>Network
                                      +--+---+   +--------+
       +-----+            +-----+        |            |  +------+
       | 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 two modes such as 2-way PMP (Point-to-
   Multipoint) and Mesh topology wireless networks.  In this document,
   we focus on 2-way PMP topology wireless networks.

   There are two different deployment options in current IEEE 802.16
   networks: Cellular-like and Hot-zone deployment scenarios.  IPv6 can
   be deployed in both of these deployment models.

   A. Cellular-like Model

   IEEE 802.16 BS can offer both fixed communications and mobile
   functions unlike IEEE 802.11.  In particular, IEEE 802.16e working
   group has been standardizing the mobility features.  The final
   specification of IEEE 802.16e will provide some competition to the
   existing cellular systems.  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 will not survive and some of them might be
   compromised to efficiently serve IPv6 to this 'Cellular-like' use
   case.

   Under the use case, however, IEEE 802.16 standards are still IP-
   centric, providing packet-switched approach, while cellular standards
   like GSM have a more circuit-switched approach.

   B. Hot Zone Model

   The success of a Hotspot service with IEEE 802.11 has been prominent.
   The new IEEE 802.16 standards basically support such Hotspot services
   with large coverage area and high data rate.  An area served 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.



Shin & Han               Expires August 27, 2006                [Page 5]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   Large numbers of wireless Internet service providers (Wireless ISPs)
   have planned to use IEEE 802.16 for the purpose of high quality
   service.  A company can use 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 of this use case is that it
   can use unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 &
   3.5GHz) band.  By using the unlicensed band, the 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, the 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 devices.

   Some of the factors that hinder deployment of native IPv6 core
   protocols include: [I-D.jee-16ng-problem-statement] [I-D.madanapalli-
   nd-over-802.16-problems].

   1.  Lacking of Facility for Native Multicasting

   IEEE 802.16 is a PMP connection oriented technology without bi-
   directional native multicast support.  IPv6 Neighbor discovery
   supports various functions for on-link determination and requires
   native multicast support.  The consequence of the lack of optimal
   multicast supports in IEEE 802.16 is that any IP protocol (e.g.  IPv4
   ARP, DHCPv4, IPv6 NDP, DHCPv6 etc.) that depends on the lower layer
   multicast support may not be able to function normally.  Especially,
   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,
   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 Sublayers can be
   efficiently used on each subnet models.  IEEE 802.16 Convergence
   Sublayer (CS) provides the tunneling of IP(v6) packets over IEEE



Shin & Han               Expires August 27, 2006                [Page 6]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   802.16 air-link.  The tunnels are identified by 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.  [IEEE802.16] defines
   several CSs for carrying IP packets, but does not provide a detailed
   description of how to carry them.  The several CSs are classified
   into two types of CS: IP CS and Ethernet CS.

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

2.2.1.  Scenario A

   Scenario A 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 and single MS.

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

   Figure 2: Scenario A

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

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.

   1.  IPv6 MS can get the IPv6 address from an access router using
   stateless auto-configuration.

   In this case Celluar-like IPv6 addressing scheme [RFC 3314] can be



Shin & Han               Expires August 27, 2006                [Page 7]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   used.  That is, a unique prefix can be allocated to each MS.  [RFC
   3314] recommends that a given prefix should be assigned to only one
   primary PDP context so that 3GPP terminals are allowed to generate
   multiple IPv6 address using the prefix without the concerns of
   address confliction (DAD).

   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.  This option is similar to what we do today in case
   of DHCPv4.

2.2.1.3.  IPv6 Control and Data Transport

   In this scenario, IEEE 802.16 connection and IPv6 termination point
   are the same, since a BS is integrated with a router.  In addition,
   each MS can be on different IPv6 link.  So, many IPv6 protocols can
   be operated without much consideration about the underlying network
   implementation.

   Only IEEE 802.16 link will be taken into consideration for IPv6
   adoption.  For example, DAD operation is not needed 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].

   Note that in this scenario IP(v6) Convergence Sublayer (CS) type may
   be more suitable to transport IPv6 packets rather than Ethernet CS
   type.

   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 is can be equally applied to other scenarios - B, C, D.

2.2.1.4.  Routing

   In general, MS/Router 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 SP network such as OSPFv3 or
   IS-IS for IPv6.  The connected prefixes have to be redistributed.



Shin & Han               Expires August 27, 2006                [Page 8]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   Prefix summarization should be done at the Edge Router.

2.2.2.  Scenario B

   Scenario B represents IEEE 802.16 access network deployment where a
   BS is integrated with a router, composing one box in view 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 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/AR and Edge Router.

2.2.2.2.  Addressing

   In this scenario, a single prefix is allocated to all the attached
   MS.  All MSs attached to same BS can be on same IPv6 link.

2.2.2.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
   IEEE 802.16 link.  So, AR/BS must support IPv6 basic protocols such
   as ND using multicast emulation functions.

   The operation and transmission methods are being intensively
   discussed in other documents [I-D.shin-16ng-ipv6-transmission].  Note
   that in this scenario Ethernet CS as well as IP CS may be used to
   transport IPv6 packets.

2.2.2.4.  Routing

   In general, MS/Router is configured with a default route that points



Shin & Han               Expires August 27, 2006                [Page 9]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   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 SP 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.3.  Scenario C

   Scenario C represents IEEE 802.16 access network deployment where a
   BS is separated from a router, and a subnet consists of only single
   BS, single router and multiple MSs.

       +-----+
       | MS1 |<------+
       +-----+       |
       +-----+       |    +-----+     +-----+    +--------+
       | MSs |<------+----| BS1 |---->| AR  |----| Edge   |    ISP
       +-----+            +-----+     +-----+    | Router +==>Network
                                         ^       +--------+
       +-----+            +-----+        |
       | Mss |<-----------| BS2 |--------+
       +-----+            +-----+
                                      <---> IP termination

   Figure 4: Scenario C

2.2.3.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 scenario the BS is Layer 3 unaware, so no changes are needed
   to support IPv6, but actually, BS should have functionalities for
   emulation of IPv6 NDP, multicast, etc.  In addition, for management
   and configuration purpose, IPv4 stack is loaded to them, BS should be
   upgraded to IPv6, too.

2.2.3.2.  Addressing

   In Figure 4, routers are located separated with IEEE 802.16 BSs.  In
   this case, IEEE 802.16 BSs have only MAC and PHY layers without
   router function.  A router and one BS form an IPv6 subnet.  Like
   scenario B, all Mss attached to same BS can be on same IPv6 link.

2.2.3.3.  IPv6 Control and Data Transport

   In a subnet, therefore, there are always two underlying links



Shin & Han               Expires August 27, 2006               [Page 10]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   including IEEE 802.16 wireless link between MS and BS.

   If stateless auto-configuration is used to get an IPv6 address,
   router discovery and DAD operations should be properly operated over
   IEEE 802.16 link.  So, AR/BS must support IPv6 basic protocols such
   as ND using multicast emulation functions.  Especially, IEEE 802.16
   connection terminates at BS, not a router.  So, BS should look at the
   classifiers and decide where to send the packet.

   The operation and transmission methods are being intensively
   discussed in other documents [I-D.shin-16ng-ipv6-transmission].  Note
   that in this scenario Ethernet CS as well as IP CS may be used to
   transport IPv6 packets.

   Simple or complex network equipments may constitute the underlying
   wired network between BS and router.  If the IP aware equipments do
   not support IPv6, the service providers are deploying IPv6-in-IPv4
   tunneling mechanisms to transport IPv6 packets between an AR and an
   Edge router.

2.2.3.4.  Routing

   In general, MS/Router 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 SP 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.4.  Scenario D

   Scenario D represents IEEE 802.16 network deployment where a BS is
   separated from a router, and a subnet consists of multiple BS and
   multiple MSs.

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




Shin & Han               Expires August 27, 2006               [Page 11]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   Figure 5: Scenario C

2.2.4.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 scenario the BS is Layer 3 unaware, so no changes are needed
   to support IPv6, but actually, BS should have functionalities for
   emulation of IPv6 NDP, multicast, etc.  In addition, for management
   and configuration purpose, IPv4 stack is loaded to them, BS should be
   upgraded to IPv6, too.

2.2.4.2.  Addressing

   In Figure 5, routers are located separated with IEEE 802.16 BSs.  In
   this case, IEEE 802.16 BSs have only MAC and PHY layers without
   router function.  A router and multiple BSs and MSs form an IPv6
   subnet.  All MSs attached to different BSs, as well as same BS can be
   on same IPv6 link.

2.2.4.3.  IPv6 Control and Data Transport

   Like scenario C, in a subnet, therefore, there are always two
   underlying links including IEEE 802.16 wireless link between MS and
   BS.  Moreover, there are multiple BSs on the same link.

   If stateless auto-configuration is used to get an IPv6 address,
   router discovery and DAD operations should be properly operated over
   IEEE 802.16 link.  So, AR/BS must support IPv6 basic protocols such
   as ND using multicast emulation functions.  Especially, IEEE 802.16
   connection terminates at BS, not a router.  So, BS should look at the
   classifiers and decide where to send the packet.  In addition, one BS
   can send the packet to other BSs, since multiple BSs are on the same
   link.

   The operation and transmission methods are being intensively
   discussed in other documents [I-D.shin-16ng-ipv6-transmission].  Note
   that in this scenario Ethernet CS may be more suitable to transport
   IPv6 packets, rather than IP CS.

   Simple or complex network equipments may constitute the underlying
   wired network between BS and router.  If the IP aware equipments do
   not support IPv6, the service providers are deploying IPv6-in-IPv4
   tunneling mechanisms to transport IPv6 packets between an AR and an
   Edge router.





Shin & Han               Expires August 27, 2006               [Page 12]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


2.2.4.4.  Routing

   In this scenario, IPv6 multi-homing considerations exist.  For
   example, there are two routers, so default router must be selected.

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

   In order to support multicast services in IEEE 802.16, Multicast
   Listener Discovery (MLD)[RFC2710] must be supported between the MS
   and BS/Router.  Also, the inter-working with IP multicast protocols
   and Multicast and Broadcast Service (MBS) should be considered.

   Within IEEE 802.16 networks, an MS connects to its BS/router via
   point-to-point links.  MLD allows an MS to send link-local multicast
   destination queries and reports.  The packets are transmitted as
   normal IEEE 802.16 MAC frames, as the same as regular unicast
   packets.  Especially, multicast CIDs can 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 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 environment may not
   always be necessary.  MLD is needed for multicast group knowledge
   that is not link-local.

   MBS defines Multicast and Broadcast Services, 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 MBS may be supported:
   single-BS access and multi-BS access.  Therefore, these two types of
   services may be roughly mapped into Source-Specific Multicast.

   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



Shin & Han               Expires August 27, 2006               [Page 13]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   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.

   In addition, IEEE 802.16 defines L2 triggers whether refresh of an IP
   address is required during the handoff.  Though a handoff has
   occurred, an additional router discovery procedure is not required in
   case of intra-subnet handoff.  Also, faster handoff may be occurred
   by the 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 procedure more efficient and faster.
   In addition, Mobile IPv6 Fast Handover assumes the support from link-
   layer technology, but the particular link-layer information being
   available, as well as the timing of its availability (before, during
   or after a handover has occurred), differs according to the
   particular link-layer technology in use.

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

2.5.  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 should be provided.

2.6.  IPv6 Security

   When initiating the connection, the MS is authenticated by the AAA
   server located at the 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 the MSs
   and once authenticated and associated successfully with BS, IPv6
   address will be acquired by the MS.  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



Shin & Han               Expires August 27, 2006               [Page 14]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


   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 with IPv6 and IPv6
   transition threat models [I-D.ietf-v6ops-security-overview].  It will
   be discussed later.

2.7.  IPv6 Network Management

   The necessary instrumentation (such as MIBs, NetFlow Records, etc)
   should be available for IPv6.

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


























Shin & Han               Expires August 27, 2006               [Page 15]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


3.  IANA Considerations

   This document requests no action by IANA.
















































Shin & Han               Expires August 27, 2006               [Page 16]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


4.  Security Considerations

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















































Shin & Han               Expires August 27, 2006               [Page 17]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


5.   Acknowledgements

   This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment-
   scenarios].  We thank all the authors of the draft.















































Shin & Han               Expires August 27, 2006               [Page 18]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


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.

   [I-D.ietf-mipshop-fast-mipv6]
              Koodli, R., "Fast Handovers for Mobile IPv6",
              draft-ietf-mipshop-fast-mipv6-03 (work in progress),
              October 2004.

6.2.  Informative References

   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
              Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
              Second and Third Generation Cellular Hosts", RFC 3316,
              April 2003.

   [I-D.madanapalli-nd-over-802.16-problems]
              Madanapalli, S., "IPv6 Neighbor Discovery over 802.16:
              Problems and Goals",
              draft-madanapalli-nd-over-802.16-problems-00 (work in
              progress), December 2005.

   [I-D.mandin-ip-over-80216-ethcs]
              Mandin, J., "Transport of IP over 802.16",
              draft-mandin-ip-over-80216-ethcs-00 (work in progress),
              October 2005.

   [I-D.jang-mipshop-fh80216e]



Shin & Han               Expires August 27, 2006               [Page 19]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


              Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
              Networks", draft-jang-mipshop-fh80216e-01 (work in
              progress), December 2005.

   [I-D.ietf-v6ops-security-overview]
              Davies, E., "IPv6 Transition/Co-existence Security
              Considerations", draft-ietf-v6ops-security-overview-03
              (work in progress), October 2005.

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

   [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 802.16e/D10 Draft, IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed and Mobile Broadband Wireless Access Systems
              Amendment for  Physical and Medium Access Control Layers
              for Combined Fixed and Mobile Operation in Licensed
              Bands", August 2005.
























Shin & Han               Expires August 27, 2006               [Page 20]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       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
   Samsung AIT
   P.O. Box 111
   Suwon 440-600
   Korea

   Email: yh21.han@gmail.com
































Shin & Han               Expires August 27, 2006               [Page 21]

Internet-Draft       IPv6 over IEEE 802.16 Scenarios       February 2006


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.




Shin & Han               Expires August 27, 2006               [Page 22]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/