draft-ietf-v6ops-802-16-deployment-scenarios-06.txt   draft-ietf-v6ops-802-16-deployment-scenarios-07.txt 
Network Working Group M-K. Shin, Ed. Network Working Group M-K. Shin, Ed.
Internet-Draft ETRI Internet-Draft ETRI
Intended status: Informational Y-H. Han Intended status: Informational Y-H. Han
Expires: June 22, 2008 KUT Expires: July 31, 2008 KUT
S-E. Kim S-E. Kim
KT KT
D. Premec D. Premec
Siemens Mobile Siemens Mobile
December 20, 2007 January 28, 2008
IPv6 Deployment Scenarios in 802.16 Networks IPv6 Deployment Scenarios in 802.16 Networks
draft-ietf-v6ops-802-16-deployment-scenarios-06 draft-ietf-v6ops-802-16-deployment-scenarios-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2008. This Internet-Draft will expire on July 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document provides a detailed description of IPv6 deployment and This document provides a detailed description of IPv6 deployment and
integration methods and scenarios in wireless broadband access integration methods and scenarios in wireless broadband access
networks in coexistence with deployed IPv4 services. In this networks in coexistence with deployed IPv4 services. In this
document we will discuss main components of IPv6 IEEE 802.16 access document we will discuss main components of IPv6 IEEE 802.16 access
networks and their differences from IPv4 IEEE 802.16 networks and how networks and their differences from IPv4 IEEE 802.16 networks and how
IPv6 is deployed and integrated in each of the IEEE 802.16 IPv6 is deployed and integrated in each of the IEEE 802.16
technologies. technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3
2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3
2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4
2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 4 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5
2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 8
2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11
2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 12 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 11
2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 12
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
As the deployment of IEEE 802.16 access networks progresses, users As the deployment of IEEE 802.16 access networks progresses, users
will be connected to IPv6 networks. While the IEEE 802.16 standard will be connected to IPv6 networks. While the IEEE 802.16 standard
defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16
MAC payload, a complete description of IPv4/IPv6 operation and MAC payload, a complete description of IPv4/IPv6 operation and
deployment is not present. The IEEE 802.16 standards are limited to deployment is not present. The IEEE 802.16 standards are limited to
skipping to change at page 3, line 29 skipping to change at page 3, line 29
and common terminology of that document. and common terminology of that document.
1.1. Terminology 1.1. Terminology
The IEEE 802.16 related terminologies in this document are to be The IEEE 802.16 related terminologies in this document are to be
interpreted as described in [I-D.ietf-16ng-ps-goals]. interpreted as described in [I-D.ietf-16ng-ps-goals].
o Subscriber Station (SS): An end-user equipment that provides o Subscriber Station (SS): An end-user equipment that provides
connectivity to the 802.16 networks. It can be either fixed/ connectivity to the 802.16 networks. It can be either fixed/
nomadic or mobile equipment. In mobile environment, SS represents nomadic or mobile equipment. In mobile environment, SS represents
the Mobile Subscriber Station (MS) introduced in [IEEE802.16e]. the Mobile Subscriber Station (MS) introduced in [IEEE802.16e].
o Base Station (BS): A generalized equipment sets providing o Base Station (BS): A generalized equipment set providing
connectivity, management, and control between the subscriber connectivity, management, and control between the subscriber
station and the 802.16 networks. station and the 802.16 networks.
o Access Router (AR): An entity that performs an IP routing function o Access Router (AR): An entity that performs an IP routing function
to provide IP connectivity for subscriber station (SS or MS). to provide IP connectivity for subscriber station (SS or MS).
o Connection Identifier (CID): A 16-bit value that identifies a o Connection Identifier (CID): A 16-bit value that identifies a
connection to equivalent peers in the 802.16 MAC of the SS(MS) and connection to equivalent peers in the 802.16 MAC of the SS(MS) and
BS. BS.
o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS specific o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS specific
part of the Packet CS defined in 802.16 STD. part of the Packet CS defined in 802.16 STD.
o IPv6 CS (Convergence Sublayer): IPv6 specific subpart of the o IPv6 CS (Convergence Sublayer): IPv6 specific subpart of the
Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD. Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.
2. Deploying IPv6 in IEEE 802.16 Networks 2. Deploying IPv6 in IEEE 802.16 Networks
2.1. Elements of IEEE 802.16 Networks 2.1. Elements of IEEE 802.16 Networks
The mechanism of transporting IP traffic over IEEE 802.16 networks is [IEEE 802.16e] is an air interface for fixed and mobile broadband
outlined in [IEEE802.16]. [IEEE802.16] only specifies the wireless access systems. [IEEE 802.16] only specifies the
convergence sublayers and the ability to transport IP over the air convergence sublayers and the ability to transport IP over the air
interface. The details of IPv6 (and IPv4) operations over IEEE interface. The details of IPv6 (and IPv4) operations over IEEE
802.16 are being discussed now in the 16ng WG. 802.16 are defined in the 16ng WG. The IPv6 over IPCS definition is
already an approved specification [I-D.ietf-16ng-ipv6-over-ipv6cs].
IP over Ethernet CS in IEEE 802.16 is defined in
[I-D.ietf-16ng-ip-over-ethernet-over-802.16].
Figure 1 illustrates the key elements of typical mobile 802.16 Figure 1 illustrates the key elements of typical mobile 802.16
deployments. deployments.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | (Backend Network) Premise | | (Backend Network)
+-----+ +----+ +----+ +--------+ +-----+ +----+ +----+ +--------+
| SSs |--(802.16)--| BS |-----| | | Edge | ISP | SSs |--(802.16)--| BS |-----| | | Edge | ISP
+-----+ +----+ | AR |---| Router |==>Network +-----+ +----+ | AR |---| Router |==>Network
skipping to change at page 5, line 5 skipping to change at page 5, line 11
discussed below. The mobile access scenario can be classified into discussed below. The mobile access scenario can be classified into
two different IPv6 link models: shared IPv6 prefix link model and two different IPv6 link models: shared IPv6 prefix link model and
point-to-point link model. point-to-point link model.
2.2.1. Mobile Access Deployment Scenarios 2.2.1. Mobile Access Deployment Scenarios
Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions
and fixed communications. [IEEE802.16e] has been standardized to and fixed communications. [IEEE802.16e] has been standardized to
provide mobility features on IEEE 802.16 environments. IEEE 802.16 provide mobility features on IEEE 802.16 environments. IEEE 802.16
BS might be deployed with a proprietary backend managed by an BS might be deployed with a proprietary backend managed by an
operator. Some architectural characteristics of IEEE 802.16 networks operator.
may affect the detailed operations of NDP (Neighbor Discovery
Protocol) [RFC4861], [RFC4862].
There are two possible IPv6 link models for mobile access deployment There are two possible IPv6 link models for mobile access deployment
scenarios: shared IPv6 prefix link model and point-to-point link scenarios: shared IPv6 prefix link model and point-to-point link
model [RFC4968]. There is always a default access router in the model [RFC4968]. There is always a default access router in the
scenarios. There can exist multiple hosts behind an MS (networks scenarios. There can exist multiple hosts behind an MS (networks
behind an MS may exist). The mobile access deployment models, Mobile behind an MS may exist). The mobile access deployment models, Mobile
WiMax and WiBro, fall within this deployment model. WiMax and WiBro, fall within this deployment model.
1. Shared IPv6 Prefix Link Model (1) Shared IPv6 Prefix Link Model
This link model represents the IEEE 802.16 mobile access network This link model represents the IEEE 802.16 mobile access network
deployment where a subnet consists of only single AR interfaces and deployment where a subnet consists of only single AR interfaces and
multiple MSs. Therefore, all MSs and corresponding AR interfaces multiple MSs. Therefore, all MSs and corresponding AR interfaces
share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix
will be different from the interface of the AR. will be different from the interface of the AR.
+-----+ +-----+
| MS1 |<-(16)-+ | MS1 |<-(16)-+
+-----+ | +-----+ +-----+ | +-----+
skipping to change at page 5, line 40 skipping to change at page 5, line 44
+->| AR |----| Edge | ISP +->| AR |----| Edge | ISP
+-----+ | +-----+ | Router +==>Network +-----+ | +-----+ | Router +==>Network
| MS3 |<-(16)-+ +-----+ | +--------+ | MS3 |<-(16)-+ +-----+ | +--------+
+-----+ +----| BS2 |--+ +-----+ +----| BS2 |--+
+-----+ | +-----+ +-----+ | +-----+
| MS4 |<-(16)-+ | MS4 |<-(16)-+
+-----+ +-----+
Figure 2: Shared IPv6 Prefix Link Model Figure 2: Shared IPv6 Prefix Link Model
2. Point-to-Point Link Model (2) Point-to-Point Link Model
This link model represents IEEE 802.16 mobile access network This link model represents IEEE 802.16 mobile access network
deployments where a subnet consists of only single AR, BS and MS. deployments where a subnet consists of only single AR, BS and MS.
That is, each connection to a mobile node is treated as a single 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, 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- unique prefix or unique set of prefixes by the AR. The point-to-
point link model follows the recommendations of [RFC3314]. point link model follows the recommendations of [RFC3314].
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MS1 |<-(16)------| |---->| | | MS1 |<-(16)------| |---->| |
skipping to change at page 6, line 27 skipping to change at page 6, line 27
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 3: Point-to-Point Link Model Figure 3: Point-to-Point Link Model
2.2.1.1. IPv6 Related Infrastructure Changes 2.2.1.1. IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16 devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16
BSs have only MAC and PHY layers without router functionality and BSs have only MAC and PHY layers without router functionality and
operate as a bridge. The BS should support IPv6 classifiers as operate as a bridge. The BS should support IPv6 classifiers as
specified in [IEEE802.16]. However, if IPv4 stack is loaded to them specified in [IEEE802.16].
for management and configuration purposes, it is expected that BS
should be upgraded by implementing IPv6 stack, too.
2.2.1.2. Addressing 2.2.1.2. Addressing
An IPv6 MS has two possible options to get an IPv6 address. These An IPv6 MS has two possible options to get an IPv6 address. These
options will be equally applied to the other scenario below (Section options will be equally applied to the other scenario below (Section
2.2.2). 2.2.2).
1. An IPv6 MS can get the IPv6 address from an access router using (1) An IPv6 MS can get the IPv6 address from an access router using
stateless auto-configuration. In this case, router discovery and DAD stateless auto-configuration. In this case, router discovery and DAD
operation should be properly operated over an IEEE 802.16 link. operation should be properly operated over an IEEE 802.16 link.
2. An IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 (2) An IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6
server. In this case, the DHCPv6 server would be located in the server. In this case, the DHCPv6 server would be located in the
service provider core network and the AR should provide a DHCPv6 service provider core network and the AR should provide a DHCPv6
relay agent. This option is similar to what we do today in case of relay agent. This option is similar to what we do today in case of
DHCPv4. DHCPv4.
In this scenario, a router and multiple BSs form an IPv6 subnet and a In this scenario, a router and multiple BSs form an IPv6 subnet and a
single prefix is allocated to all the attached MSs. All MSs attached single prefix is allocated to all the attached MSs. All MSs attached
to same AR can be on the same IPv6 link. to same AR can be on the same IPv6 link.
As for the prefix assignment, in case of the shared IPv6 prefix link As for the prefix assignment, in case of the shared IPv6 prefix link
skipping to change at page 7, line 15 skipping to change at page 7, line 13
to-point link model, the AR assigns a unique prefix or a set of to-point link model, the AR assigns a unique prefix or a set of
unique prefixes for each MS. Prefix delegation can be required if unique prefixes for each MS. Prefix delegation can be required if
networks exist behind an MS. networks exist behind an MS.
2.2.1.3. IPv6 Transport 2.2.1.3. IPv6 Transport
In an IPv6 subnet, there are always two underlying links: one is the In an IPv6 subnet, there are always two underlying links: one is the
IEEE 802.16 wireless link between the MS and BS, and the other is a IEEE 802.16 wireless link between the MS and BS, and the other is a
wired link between the BS and AR. wired link between the BS and AR.
If stateless auto-configuration is used to get an IPv6 address, IPv6 packets can be sent and received via the IP specific part of the
router discovery and DAD operation should be properly operated over packet convergence sublayer. The Packet CS is used for the transport
IEEE 802.16 links. In case of the shared IPv6 prefix link model, the of packet based protocols which include Ethernet and Internet
DAD (Duplicate Address Detection) [RFC4861] does not adapt well to Protocol (IPv4 and IPv6). Note that in this scenario IPv6 CS may be
the 802.16 air interface as there is no native multicast support. An more appropriate than Ethernet CS to transport IPv6 packets, since
optimization, called Relay DAD, may be required to perform DAD. there is some overhead of Ethernet CS (e.g., Ethernet header) under
However, in case of the point-to-point link model, DAD is easy since mobile access environments. However, when PHS (Payload Header
each connection to a MN is treated as a unique IPv6 link. Suppression) is deployed it mitigates this overhead through the
compression of packet headers. The details of IPv6 operations over
Note that in this scenario IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] the IP specific part of the packet CS defined in
may be more appropriate than Ethernet CS [I-D.ietf-16ng-ip-over- [I-D.ietf-16ng-ipv6-over-ipv6cs].
ethernet-over-802.16] to transport IPv6 packets, since there is some
overhead of Ethernet CS (e.g., Ethernet header) under mobile access
environments. However, when PHS (Payload Header Suppression) is
deployed it mitigates this overhead through the compression of packet
headers.
Simple or complex network equipment may constitute the underlying Simple or complex network equipment may constitute the underlying
wired network between the AR and the ER. If the IP-aware equipment wired network between the AR and the ER. If the IP-aware equipment
between the AR and the ER does not support IPv6, the service between the AR and the ER does not support IPv6, the service
providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport
IPv6 packets between the AR and the ER. IPv6 packets between the AR and the ER.
The service providers are deploying tunneling mechanisms to transport The service providers are deploying tunneling mechanisms to transport
IPv6 over their existing IPv4 networks as well as deploying native IPv6 over their existing IPv4 networks as well as deploying native
IPv6 where possible. Native IPv6 should be preferred over tunneling IPv6 where possible. Native IPv6 should be preferred over tunneling
skipping to change at page 8, line 16 skipping to change at page 8, line 8
The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740] The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740]
or IS-IS for IPv6 when connected to the ER with multiple links. or IS-IS for IPv6 when connected to the ER with multiple links.
The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service
provider network. The routing information of the ER can be provider network. The routing information of the ER can be
redistributed to the AR. Prefix summarization should be done at the redistributed to the AR. Prefix summarization should be done at the
ER. ER.
2.2.1.5. Mobility 2.2.1.5. Mobility
As for mobility management, the movement between BSs is handled by There are two types of handovers for the IEEE 802.16e networks: link
Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in layer handover and IP layer handover. In a link layer handover, BSs
certain cases (e.g., fast handover) the link mobility information involved in the handover reside in the same IP subnet. A MS only
must be available for facilitating the layer 3 handoff procedure. needs to re-establish a link layer connection with a new BS without
changing its IP configuration, such as its IP address, default
router, on-link prefix, etc. The link layer handover in IEEE 802.16e
is by nature a hard handover since the MS has to cut off the
connection with the current BS at the beginning of the handover
process and cannot resume communication with the new BS until the
handover completes [IEEE802.16e]. In an IP layer handover, the BSs
involved reside in different IP subnets, or in different networks.
Thus, in an IP layer handover, a MS needs to establish both a new
link layer connection, as in a link layer handover, and a new IP
configuration to maintain connectivity.
IP layer handover for MSs is handled by Mobile IPv6 [RFC3775].
Mobile IPv6 defines that movement detection uses Neighbor Mobile IPv6 defines that movement detection uses Neighbor
Unreachability Detection to detect when the default router is no Unreachability Detection to detect when the default router is no
longer bidirectionally reachable, in which case the mobile node must longer bidirectionally reachable, in which case the mobile node must
discover a new default router. Periodic Router Advertisements for discover a new default router. Periodic Router Advertisements for
reachability and movement detection may be unnecessary because the reachability and movement detection may be unnecessary because the
IEEE 802.16 MAC provides the reachability by its Ranging procedure IEEE 802.16 MAC provides the reachability by its ranging procedure
and the movement detection by the Handoff procedure. and the movement detection by the Handoff procedure.
IEEE 802.16 defines L2 triggers in case the refresh of an IP address Mobile IPv6 alone will not solve the handover latency problem for the
is required during the handoff. Though a handoff has occurred, an IEEE 802.16e networks. To reduce or eliminate packet loss and to
additional router discovery procedure is not required in case of reduce the handover delay in Mobile IPv6, therefore, Fast Handover
intra-subnet handoff. Also, faster handoff may occur by the L2 for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with
trigger in case of inter-subnet handoff. MIPv6. To perform predictive packet forwarding, the FMIPv6's IP
layer assumes the presence of handover-related triggers delivered by
the IEEE 802.16 MAC layers. Thus, there is a need for cross-layering
design to support proper behavior of the FMIPv6 solution. This issue
is also being discussed in [I-D.ietf-mipshop-fh80216e].
Also, [IEEE802.16g] defines L2 triggers for link status such as Also, [IEEE802.16g] defines L2 triggers for link status such as
link-up, link-down, handoff-start. These L2 triggers may make the link-up, link-down, handoff-start. These L2 triggers may make the
Mobile IPv6 procedure more efficient and faster. In addition, Mobile Mobile IPv6 or FMIPv6 procedure more efficient and faster.
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.ietf-mipshop-fh80216e].
In addition, due to the problems caused by the existence of multiple
convergence sublayers [RFC4840], the mobile access scenarios need
solutions about how roaming will work when forced to move from one CS
to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase
this issue is the out of scope of this document. It should be also
discussed in the 16ng WG.
2.2.2. Fixed/Nomadic Deployment Scenarios 2.2.2. Fixed/Nomadic Deployment Scenarios
The IEEE 802.16 access networks can provide plain Ethernet end-to-end The IEEE 802.16 access networks can provide plain Ethernet end-to-end
connectivity. Wireless DSL deployment model is an example of a connectivity. This scenario represents deployment model using
fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet Ethernet CS. Wireless DSL deployment model is an example of a fixed/
nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet
service providers (Wireless ISPs) have planned to use IEEE 802.16 for service providers (Wireless ISPs) have planned to use IEEE 802.16 for
the purpose of high quality broadband wireless services. A company the purpose of high quality broadband wireless services. A company
can use IEEE 802.16 to build up a mobile office. Wireless Internet can use IEEE 802.16 to build up a mobile office. Wireless Internet
spreading through a campus or a cafe can be also implemented with it. spreading through a campus or a cafe can be also implemented with it.
The distinct point of this use case is that it can use the unlicensed
(2.4 & 5 GHz) band as well as the licensed (2.6 & 3.5GHz) band. By
using the unlicensed band, an IEEE 802.16 BS might be used just as a
wireless switch/hub which a user purchases to build a private
wireless network in his/her home or laboratory.
Under fixed access model, the IEEE 802.16 BS will be deployed using
an IP backbone rather than a proprietary backend like cellular
systems. Thus, many IPv6 functionalities such as [RFC4861],
[RFC4862] will be preserved when adopting IPv6 to IEEE 802.16
devices.
+-----+ +-----+ +-----+ ISP 1 +-----+ +-----+ +-----+ ISP 1
| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network | SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network
+-----+ | | +-----+ +-----+ +-----+ | | +-----+ +-----+
+-----+ | +-----+ | +-----+ | +-----+ |
| SS2 |<-(16)+-----| BS1 |--| | SS2 |<-(16)+-----| BS1 |--|
+-----+ +-----+ | +-----+ +-----+ ISP 2 +-----+ +-----+ | +-----+ +-----+ ISP 2
+->| AR2 |----| ER2 |===>Network +->| AR2 |----| ER2 |===>Network
+-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ +-----+
|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+ |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
skipping to change at page 10, line 32 skipping to change at page 10, line 14
In this approach the 802.16 BS is acting as a DSLAM (Digital In this approach the 802.16 BS is acting as a DSLAM (Digital
Subscriber Line Access Multiplexer). On the network side, the BS is Subscriber Line Access Multiplexer). On the network side, the BS is
connected to an Ethernet bridge which can be separate equipment or connected to an Ethernet bridge which can be separate equipment or
integrated into the BRAS (Broadband Remote Access Server). integrated into the BRAS (Broadband Remote Access Server).
2.2.2.1. IPv6 Related Infrastructure Changes 2.2.2.1. IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: MS, AR, ER, and the Ethernet Bridge. The BS devices to dual-stack: MS, AR, ER, and the Ethernet Bridge. The BS
should support IPv6 classifiers as specified in [IEEE802.16]. should support IPv6 classifiers as specified in [IEEE802.16].
However, if a IPv4 stack is loaded to them for management and
configuration purpose, it is expected that the BS should be upgraded
by implementing an IPv6 stack, too.
The BRAS in Figure 5 is providing the functionality of the AR. An The BRAS in Figure 5 is providing the functionality of the AR. An
Ethernet bridge is necessary for protecting the BRAS from 802.16 link Ethernet bridge is necessary for protecting the BRAS from 802.16 link
layer peculiarities. The Ethernet bridge relays all traffic received layer peculiarities. The Ethernet bridge relays all traffic received
through the BS to its network side port(s) connected to the BRAS. through the BS to its network side port(s) connected to the BRAS.
Any traffic received from the BRAS is relayed to the appropriate BS. Any traffic received from the BRAS is relayed to the appropriate BS.
Since the 802.16 MAC layer has no native support for multicast (and Since the 802.16 MAC layer has no native support for multicast (and
broadcast) in the uplink direction, the Ethernet bridge will broadcast) in the uplink direction, the Ethernet bridge will
implement multicast (and broadcast) by relaying the multicast frame implement multicast (and broadcast) by relaying the multicast frame
received from the MS to all of its ports. The Ethernet bridge may received from the MS to all of its ports. The Ethernet bridge may
also provide some IPv6 specific functions to increase link efficiency also provide some IPv6 specific functions to increase link efficiency
of the 802.16 radio link (see Section 2.2.2.3). of the 802.16 radio link (see Section 2.2.2.3).
2.2.2.2. Addressing 2.2.2.2. Addressing
One or more IPv6 prefixes can be shared to all the attached MSs. One or more IPv6 prefixes can be shared to all the attached MSs.
Prefix delegation can be required if networks exist behind the SS. Prefix delegation can be required if networks exist behind the SS.
2.2.2.3. IPv6 Transport 2.2.2.3. IPv6 Transport
Note that in this scenario Ethernet CS Transmisson of IPv6 over Ethernet CS follows [RFC2464] and does not
[I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate introduce any changes to [RFC4861] and [RFC4862]. However, there are
than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6 a few considerations in the viewpoint of operation, such as
packets, since the scenario needs to support plain Ethernet end-to- preventing periodic router advertisement messages from an access
end connectivity. However, the IPv6 CS can also be supported. The router and broadcast transmission, deciding path MTU size, and so on.
MS and BS will consider the connections between the peer IP CSs at The details about the considerations are described in
the MS and BS to form a point to point link. In the Ethernet CS [I-D.ietf-16ng-ip-over-ethernet-over-802.16].
case, an Ethernet bridge may provide implementation of an
authoritative address cache and Relay DAD. An Authoritative address
cache is a 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 the Neighbor Solicitation message used in the
DAD process will be relayed only to the MS which already has
configured the solicited address as its own address (if such an MS
exist at all).
2.2.2.4. Routing 2.2.2.4. Routing
In this scenario, IPv6 multi-homing considerations exist. For In this scenario, IPv6 multi-homing considerations exist. For
example, if there exist two routers to support MSs, a default router example, if there exist two routers to support MSs, a default router
must be selected. must be selected.
The Edge Router runs the IGP used in the SP network such as OSPFv3 The Edge Router runs the IGP used in the SP network such as OSPFv3
[RFC2740] or IS-IS for IPv6. The connected prefixes have to be [RFC2740] or IS-IS for IPv6. The connected prefixes have to be
redistributed. Prefix summarization should be done at the Edge redistributed. Prefix summarization should be done at the Edge
Router. Router.
2.2.2.5. Mobility 2.2.2.5. Mobility
No mobility functions are supported in the fixed access scenario. No mobility functions of Layer 2 and Layer 3 are supported in the
However, mobility can be supported in the radio coverage without any fixed access scenario. Like WLAN technology, however, nomadicity can
mobility protocol like WLAN technology. Therefore, a user can access be supported in the radio coverage without any mobility protocol.
Internet nomadically in the coverage. So, a user can access Internet nomadically in the coverage.
2.3. IPv6 Multicast
In IEEE 802.16 air link, downlink connections can be shared among
multiple MSs, enabling multicast channels with multiple MSs receiving
the same information from the BS. Multicast and Broadcast Service
(MBS) may be used to efficiently implement multicast. However, it is
not clear how to do this, as currently CID is assigned by BS, but in
MBS it should be done at an AR and it's network scope. It is not
clear how this mapping will happen for MBS, so MBS discussions have
been postponed in WiMax for now. Note that it should be intensively
researched later, since MBS will be one of the killer services in
IEEE 802.16 networks.
In order to support multicast services in IEEE 802.16, Multicast Sometime, service users can demand IP session continuity or home
Listener Discovery (MLD) [RFC2710] must be supported between the MS address reusability even in the nomadic environment. In case of
and AR. Also, the inter-working with IP multicast protocols and MBS that, Mobile IPv6 [RFC3775] may be used in this scenario even in the
should be considered. absence of Layer 2's mobility support.
MBS defines Multicast and Broadcast Services, but actually, MBS seems 2.3. IPv6 Multicast
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: [I-D.ietf-16ng-ip-over-ethernet-over-802.16] realizes IPv6 multicast
single-BS access and multi-BS access. Therefore, these two types of support by IGMP/MLD proxying [RFC4605] and IGMP/MLD snooping
services may be roughly mapped into Source-Specific Multicast. [RFC4541]. Additionally, it may be possible to efficiently implement
multicast packet transmission among the multicast subscribers by
means of IEEE 802.16 Multicast CIDs. However, such a protocol is not
yet available and under development in WiMAX Forum.
2.4. IPv6 QoS 2.4. IPv6 QoS
In IEEE 802.16 networks, a connection is unidirectional and has a QoS In IEEE 802.16 networks, a connection is unidirectional and has a QoS
specification. The 802.16 supported QoS has different semantics from specification. Each connection is associated with a single data
IP QoS (e.g., diffserv). Mapping CID to Service Flow IDentifier service flow and each service flow is associated with a set of QoS
(SFID) defines QoS parameters of the service flow associated with parameters in [IEEE802.16]. The QoS related parameters are managed
that connection. In order to interwork with IP QoS, IP QoS (e.g., using the Dynamic Service Addition (DSA) and Dynamic Service Change
diffserv, or flow label for IPv6) mapping to IEEE 802.16 link (DSC) MAC management messages that specified in [IEEE802.16]. The
specifics should be provided. [IEEE802.16] provides QoS differentiation for the different types of
applications by five scheduling service. Four scheduling services
are defined in 802.16 such as Unsolicited Grant Service (UGS), real-
time Polling Service (rtPS), non-real-time Polling Service (nrtPS)
and Best Effort (BE). A fifth scheduling service is Extended Real-
time Polling Service (ertPS) that is defined in [IEEE802.16e]. It is
required to provide IP layer quality of service mapping to MAC layer
QoS types [IEEE802.16], [IEEE802.16e].
2.5. IPv6 Security 2.5. IPv6 Security
When initiating the connection, an MS is authenticated by the AAA When initiating the connection, an MS is authenticated by the AAA
server located at its service provider network. All the parameters server located at its service provider network. To achieve that, the
related to authentication (username, password and etc.) are forwarded MS and the BS use Privacy Key Management [IEEE802.16],[IEEE802.16e],
by the BS to the AAA server. The AAA server authenticates the MSs while the BS communicates with the AAA server using a AAA protocol.
and when an MS is once authenticated and associated successfully with Once the MS is authenticated with the AAA server, it can associate
BS, IPv6 an address will be acquired by the MS through stateless successfully with the BS and acquire an IPv6 address through
autoconfiguration or DHCPv6. Note the initiation and authentication stateless autoconfiguration or DHCPv6. Note that the initiation and
process is the same as used in IPv4. authentication process is the same as the one used in IPv4.
IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may
be used within the global end-to-end architecture. But, we do not
have PKIs across organizations and IPsec is not integrated with IEEE
802.16 network mobility management.
IEEE 802.16 network threats may be different from IPv6 and IPv6
transition threat models [RFC4942]. It should be also discussed.
2.6. IPv6 Network Management 2.6. IPv6 Network Management
[IEEE802.16f] includes the management information base for IEEE [IEEE802.16f] includes the management information base for IEEE
802.16 networks. For IPv6 network management, the necessary 802.16 networks. For IPv6 network management, the necessary
instrumentation (such as MIBs, NetFlow Records, etc) should be instrumentation (such as MIBs, NetFlow Records, etc) should be
available. available.
Upon entering the network, an MS is assigned three management Upon entering the network, an MS is assigned three management
connections in each direction. These three connections reflect the connections in each direction. These three connections reflect the
skipping to change at page 13, line 37 skipping to change at page 12, line 37
management systems (NMS) can send SNMP messages by IPv4 with IPv6 management systems (NMS) can send SNMP messages by IPv4 with IPv6
related object identifiers. Also, an NMS can use IPv6 for SNMP related object identifiers. Also, an NMS can use IPv6 for SNMP
requests and responses including IPv4 related OID. requests and responses including IPv4 related OID.
3. IANA Considerations 3. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
4. Security Considerations 4. Security Considerations
Please refer to Section 2.5 "IPv6 Security" technology sections for This document provides a detailed description of various IPv6
details. deployment scenarios and link models for IEEE 802.16 based networks,
and as such does not introduce any new security threats. No matter
what the scenario applied is, the networks should employ the same
link-layer security mechanisms defined in [IEEE802.16e] and IPv6
transition security considerations defined in [RFC4942]. However, as
already described in [RFC4968], a shared prefix model based mobile
access deployment scenario may security implications for protocols
that are designed to work within the scope. This is the concern for
a shared prefix link model wherein private resources cannot be put
onto a public 802.16 based networks. This may restrict the usage of
a shared prefix model to enterprise environments.
5. Acknowledgements 5. Acknowledgements
This work extends v6ops work on [RFC4779]. We thank all the authors This work extends v6ops work on [RFC4779]. We thank all the authors
of the document. Special thanks are due to Maximilian Riegel, Jonne of the document. Special thanks are due to Maximilian Riegel, Jonne
Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj
Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin
Jeong, and Jinhyeock Choi for extensive review of this document. We Jeong, and Jinhyeock Choi for extensive review of this document. We
acknowledge Dominik Kaspar for proofreading the document. acknowledge Dominik Kaspar for proofreading the document.
skipping to change at page 14, line 16 skipping to change at page 13, line 25
6.1. Normative References 6.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
6.2. Informative References 6.2. Informative References
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
J. Palet, "ISP IPv6 Deployment Scenarios in Broadband J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", RFC 4779, January 2007. Access Networks", RFC 4779, January 2007.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007. Based Networks", RFC 4968, August 2007.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
skipping to change at page 14, line 43 skipping to change at page 13, line 48
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999. RFC 2740, December 1999.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002. RFC 3314, September 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Encapsulation Methods Considered Harmful", RFC 4840, Networks", RFC 2464, December 1998.
April 2007.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[I-D.ietf-16ng-ps-goals] [I-D.ietf-16ng-ps-goals]
Jee, J., Madanapalli, S., Mandin, J., and S. Park, "IP Jee, J., Madanapalli, S., and J. Mandin, "IP over 802.16
over 802.16 Problem Statement and Goals", Problem Statement and Goals", draft-ietf-16ng-ps-goals-04
draft-ietf-16ng-ps-goals-03 (work in progress), (work in progress), December 2007.
November 2007.
[I-D.ietf-16ng-ipv6-over-ipv6cs] [I-D.ietf-16ng-ipv6-over-ipv6cs]
Patil, B., Xia, F., Sarikaya, B., Choi, J., and S. Patil, B., Xia, F., Sarikaya, B., Choi, J., and S.
Madanapalli, "Transmission of IPv6 via the IPv6 CS over Madanapalli, "Transmission of IPv6 via the IPv6 CS over
IEEE 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-11 IEEE 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-11
(work in progress), November 2007. (work in progress), November 2007.
[I-D.ietf-16ng-ip-over-ethernet-over-802.16] [I-D.ietf-16ng-ip-over-ethernet-over-802.16]
Jeon, H., "Transmission of IP over Ethernet over IEEE Jeon, H., "Transmission of IP over Ethernet over IEEE
802.16 Networks", 802.16 Networks",
draft-ietf-16ng-ip-over-ethernet-over-802.16-03 (work in draft-ietf-16ng-ip-over-ethernet-over-802.16-04 (work in
progress), November 2007. progress), January 2008.
[I-D.ietf-mipshop-fh80216e] [I-D.ietf-mipshop-fh80216e]
Jang, H., Jee, J., Han, Y., Park, S., and J. Cha, "Mobile Jang, H., Jee, J., Han, Y., Park, S., and J. Cha, "Mobile
IPv6 Fast Handovers over IEEE 802.16e Networks", IPv6 Fast Handovers over IEEE 802.16e Networks",
draft-ietf-mipshop-fh80216e-05 (work in progress), draft-ietf-mipshop-fh80216e-05 (work in progress),
November 2007. November 2007.
[IEEE802.16] [IEEE802.16]
"IEEE 802.16-2004, IEEE Standard for Local and "IEEE 802.16-2004, IEEE Standard for Local and
Metropolitan Area Networks, Part 16: Air Interface for Metropolitan Area Networks, Part 16: Air Interface for
skipping to change at page 17, line 7 skipping to change at page 17, line 7
Domagoj Premec Domagoj Premec
Siemens Mobile Siemens Mobile
Heinzelova 70a Heinzelova 70a
10010 Zagreb 10010 Zagreb
Croatia Croatia
Email: domagoj.premec@siemens.com Email: domagoj.premec@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 39 change blocks. 
169 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/