draft-ietf-v6ops-802-16-deployment-scenarios-02.txt   draft-ietf-v6ops-802-16-deployment-scenarios-03.txt 
Network Working Group M-K. Shin Network Working Group M-K. Shin
Internet-Draft ETRI Internet-Draft ETRI
Intended status: Informational Y-H. Han Expires: August 17, 2007 Y-H. Han
Expires: July 20, 2007 KUT KUT
S-E. Kim S-E. Kim
KT KT
D. Premec D. Premec
Siemens Mobile Siemens Mobile
January 16, 2007 February 13, 2007
IPv6 Deployment Scenarios in 802.16(e) Networks IPv6 Deployment Scenarios in 802.16 Networks
draft-ietf-v6ops-802-16-deployment-scenarios-02 draft-ietf-v6ops-802-16-deployment-scenarios-03
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 July 20, 2007. This Internet-Draft will expire on August 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides detailed description of IPv6 deployment and This document provides 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
network and its differences from IPv4 IEEE 802.16 networks and how network and its 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 using tunneling mechanisms and native IPv6. technologies using tunneling mechanisms and native IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4
2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4
2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 5 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 5
2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5
2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9
2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 12 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 12
2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 13 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 13
2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
As the deployment of IEEE 802.16(e) access network progresses, users As the deployment of IEEE 802.16(e) access network progresses, users
will be connected to IPv6 networks. While the IEEE 802.16 defines 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 the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 MAC
payload, a complete description of IPv4/IPv6 operation and deployment payload, a complete description of IPv4/IPv6 operation and deployment
is not present. In this document, we will discuss main components of is not present. In this document, we will discuss main components of
IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 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 802.16 networks and how IPv6 is deployed and integrated in each of
the IEEE 802.16 technologies using tunneling mechanisms and native the IEEE 802.16 technologies using tunneling mechanisms and native
IPv6. IPv6.
This document extends works of [I-D.ietf-v6ops-bb-deployment- This document extends works of [RFC4779] and follows the structure
scenarios] and follows the structure and common terminology of the and common terminology of the document.
document.
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 The mechanism of transporting IP traffic over IEEE 802.16 networks is
outlined in [IEEE802.16]. [IEEE802.16] only specifies the outlined in [IEEE802.16]. [IEEE802.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 16ng WG. 802.16 are being discussed now in 16ng WG.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
provide nomadic access within the radio coverages, which is called provide nomadic access within the radio coverages, which is called
Hot-zone model. A mobile access scenario is for new paradigm for Hot-zone model. A mobile access scenario is for new paradigm for
voice, data and video over mobile network. This scenario can provide voice, data and video over mobile network. This scenario can provide
high speed data rate equalivent to wire-based Internet as well as high speed data rate equalivent to wire-based Internet as well as
mobility function equivalent to cellular system. The mobile access mobility function equivalent to cellular system. The mobile access
scenario can be classified into two different IPv6 link models: scenario can be classified into two different IPv6 link models:
shared IPv6 prefix link model and point-to-point link model. shared IPv6 prefix link model and point-to-point link model.
2.2.1. Mobile Access Deployment Scenarios 2.2.1. Mobile Access Deployment Scenarios
Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as Unlike IEEE 802.11, The IEEE 802.16 BS can provide mobility functions
well as fixed communication. [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. Some architectural characteristics of IEEE 802.16 networks
may affect the detailed operations of NDP [RFC2461], [RFC2462]. may affect the detailed operations of NDP [RFC2461], [RFC2462].
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 [I-D.ietf-16ng-ipv6-link-model-analysis]. There is alwayes a model [I-D.ietf-16ng-ipv6-link-model-analysis]. There is always a
default access router in the scenarios. There exist multiple hosts default access router in the scenarios. There can exist multiple
behind an MS (networks behind an MS may exist). The mobile access hosts behind an MS (networks behind an MS may exist). The mobile
deployment models, Mobile WiMax and WiBro, fall within this access deployment models, Mobile WiMax and WiBro, fall within this
deployment model. deployment model.
1. Shared IPv6 Prefix Link Model 1. Shared IPv6 Prefix Link Model
This link model represents IEEE 802.16 mobile access network This link model represents IEEE 802.16 mobile access network
deployment where a subnet consists of only single interface of AR and deployment where a subnet consists of only single interface of AR and
multiple MSs. Therefore, all MSs and corresponding interface of AR multiple MSs. Therefore, all MSs and corresponding interface of AR
share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be
different from the interface of AR. different from the interface of AR.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
| MS4 |<-(16)---------+ | MS4 |<-(16)---------+
+-----+ +-----+
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 function and operates 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 IPv4 as a bridge. The BS should support IPv6 classifiers as specified in
stack is loaded to them for management and configuration purpose, it [IEEE802.16]. However, if IPv4 stack is loaded to them for
is expected that BS should be upgraded by implementing IPv6 stack, management and configuration purpose, it is expected that BS should
too. be upgraded by implementing IPv6 stack, too.
2.2.1.2. Addressing 2.2.1.2. Addressing
IPv6 MS has two possible options to get an IPv6 address. These 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. IPv6 MS can get the IPv6 address from an access router using 1. 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 IEEE 802.16 link. operation should be properly operated over IEEE 802.16 link.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
As for the prefix assignment, in case of shared IPv6 prefix link As for the prefix assignment, in case of shared IPv6 prefix link
model, one or more IPv6 prefixes are assigned to the link and hence model, one or more IPv6 prefixes are assigned to the link and hence
shared by all the nodes that are attached to the link. In point-to- 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 point link model, the AR assigns a unique prefix or set of unique
prefixes for each MS. Prefix delegation can be required if networks prefixes for each MS. Prefix delegation can be required if networks
can exist behind MS. can exist behind MS.
2.2.1.3. IPv6 Transport 2.2.1.3. IPv6 Transport
In a subnet, there are always two underlying links: one is the IEEE In an IPv6 subnet, there are always two underlying links: one is the
802.16 wireless link between MS and BS, and the other is a wired link IEEE 802.16 wireless link between MS and BS, and the other is a wired
between BS and AR. The IPv6 packet should be classified by IPv6 link between BS and AR.
source/destination addresses, etc. BS generates the flow based on
the 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, If stateless auto-configuration is used to get an IPv6 address,
router discovery and DAD operation should be properly operated over router discovery and DAD operation should be properly operated over
IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD
[RFC2461] does not adapt well to the 802.16 air interface as there is [RFC2461] does not adapt well to the 802.16 air interface as there is
no native multicast support. An optimization, called Relay DAD, may no native multicast support. An optimization, called Relay DAD, may
be required to perform DAD. However, in case of point-to-point link be required to perform DAD. However, in case of point-to-point link
model, DAD is easy since each connection to a MN is treated as a model, DAD is easy since each connection to a MN is treated as a
unique IPv6 link. unique IPv6 link.
Note that in this scenario IPv6 CS may be more appropriate than Note that in this scenario IPv6 CS may be more appropriate than
Ethernet CS to transport IPv6 packets, since there are some overhead Ethernet CS to transport IPv6 packets, since there are some overhead
of Ethernet CS (e.g., Ethernet header) under mobile access of Ethernet CS (e.g., Ethernet header) under mobile access
environments. However PHS (Packet Header Compression), if deployed, environments. However, when PHS (Payload Header Suppression) is
mitigates much of this overhead. deployed it mitigates this overhead through the compression of packet
headers.
Simple or complex network equipments may constitute the underlying Simple or complex network equipments may constitute the underlying
wired network between the AR and the ER. If the IP aware equipments wired network between the AR and the ER. If the IP aware equipments
between the AR and the ER do not support IPv6, the service providers between the AR and the ER do not support IPv6, the service providers
can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6
packets between the AR and the ER. 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 9, line 13 skipping to change at page 9, line 11
reachability and movement detection may be unnecessary because IEEE reachability and movement detection may be unnecessary because IEEE
802.16 MAC provides the reachability by its Ranging procedure and the 802.16 MAC provides the reachability by its Ranging procedure and the
movement detection by the Handoff procedure. movement detection by the Handoff procedure.
IEEE 802.16 defines L2 triggers whether refresh of an IP address is IEEE 802.16 defines L2 triggers whether refresh of an IP address is
required during the handoff. Though a handoff has occurred, an required during the handoff. Though a handoff has occurred, an
additional router discovery procedure is not required in case of additional router discovery procedure is not required in case of
intra-subnet handoff. Also, faster handoff may be occurred by the L2 intra-subnet handoff. Also, faster handoff may be occurred by the L2
trigger in case of inter-subnet handoff. trigger in case of inter-subnet handoff.
Also, IEEE 802.16g which is under-developed defines L2 triggers for Also, [IEEE802.16g] which is under-developed defines L2 triggers for
link status such as link-up, link-down, handoff-start. These L2 link status such as link-up, link-down, handoff-start. These L2
triggers may make Mobile IPv6 procedure more efficient and faster. triggers may make Mobile IPv6 procedure more efficient and faster.
In addition, Mobile IPv6 Fast Handover assumes the support from link- In addition, Mobile IPv6 Fast Handover assumes the support from link-
layer technology, but the particular link-layer information being layer technology, but the particular link-layer information being
available, as well as the timing of its availability (before, during available, as well as the timing of its availability (before, during
or after a handover has occurred), differs according to the or after a handover has occurred), differs according to the
particular link-layer technology in use. This issue is also being particular link-layer technology in use. This issue is also being
discussed in [I-D.ietf-mipshop-fh80216e]. discussed in [I-D.ietf-mipshop-fh80216e].
In addition, due to the problems caused by the existence of multiple In addition, due to the problems caused by the existence of multiple
convergence sublayers [I-D.iab-link-encaps], the mobile access convergence sublayers [I-D.iab-link-encaps], the mobile access
scenarios need solutions about how roaming will work when forced to 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 move from one CS to another (e.g., IPv6 CS to Ethernet CS). Note
the out of scope of this draft. It should be also discussed in 16ng that, at this phase this issue is the out of scope of this draft. It
WG. should be also discussed in 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 The IEEE 802.16 access networks can provide plain Ethernet
connectivity end-to-end. Wireless DSL deployment model is an example connectivity end-to-end. Wireless DSL deployment model is an example
of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless
Internet service providers (Wireless ISPs) have planned to use IEEE Internet service providers (Wireless ISPs) have planned to use IEEE
802.16 for the purpose of high quality broadband wireless service. A 802.16 for the purpose of high quality broadband wireless service. A
company can use IEEE 802.16 to build up mobile office. Wireless company can use IEEE 802.16 to build up mobile office. Wireless
Internet spreading through a campus or a cafe can be also implemented Internet spreading through a campus or a cafe can be also implemented
skipping to change at page 11, line 8 skipping to change at page 11, line 8
Figure 5: Integration of 802.16 access into DSL infrastructure Figure 5: Integration of 802.16 access into DSL infrastructure
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 BRAS (Broadband Remote Access Server). integrated into 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 and ER. In this scenario, IEEE 802.16 devices to dual-stack: MS, AR, ER and Ethernet Bridge. The BS should
BSs have only MAC and PHY layers without router function and operates support IPv6 classifiers as specified in [IEEE802.16]. However, if
as a bridge. The BS does not need to support IPv6. However, if IPv4 IPv4 stack is loaded to them for management and configuration
stack is loaded to them for management and configuration purpose, it purpose, it is expected that BS should be upgraded by implementing
is expected that BS should be upgraded by implementing IPv6 stack, IPv6 stack, too.
too.
The BRAS in Figure 5 is providing the functionality of the AR. The The BRAS in Figure 5 is providing the functionality of the AR. The
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 BS to its network side port(s) connected to BRAS. Any through BS to its network side port(s) connected to BRAS. Any
traffic received from BRAS is relayed to appropriate BS. Since traffic received from BRAS is relayed to appropriate BS. Since
802.16 MAC layer has no native support for multicast (and broadcast) 802.16 MAC layer has no native support for multicast (and broadcast)
in the uplink direction, the Ethernet bridge will implement multicast in the uplink direction, the Ethernet bridge will implement multicast
(and broadcast) by relaying the multicast frame received from the MS (and broadcast) by relaying the multicast frame received from the MS
to all of its ports. The Ethernet bridge may also provide some IPv6 to all of its ports. The Ethernet bridge may also provide some IPv6
skipping to change at page 13, line 8 skipping to change at page 12, line 48
multicast routing using a shared tree or source-specific tree to multicast routing using a shared tree or source-specific tree to
deliver packets efficiently. deliver packets efficiently.
In IEEE 802.16 networks, two types of access to MBS may be supported: 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 single-BS access and multi-BS access. Therefore, these two types of
services may be roughly mapped into Source-Specific Multicast. services may be roughly mapped into Source-Specific Multicast.
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 QoS has different semantics with IP QoS (e.g., specification. The 802.16 supported QoS has different semantics from
diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS IP QoS (e.g, diffserv). Mapping CID to Service Flow IDentifier
parameters of the service flow associated with that connection. In (SFID) defines QoS parameters of the service flow associated with
order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label that connection. In order to interwork with IP QoS, IP QoS (e.g.,
for IPv6) mapping to IEEE 802.16 link specifics should be provided. diffserv, or flow label for IPv6) mapping to IEEE 802.16 link
specifics should be provided.
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. All the parameters
related to authentication (username, password and etc.) are forwarded related to authentication (username, password and etc.) are forwarded
by the BS to the AAA server. The AAA server authenticates the MSs by the BS to the AAA server. The AAA server authenticates the MSs
and once authenticated. When an MS is once authenticated and and once authenticated. When an MS is once authenticated and
associated successfully with BS, IPv6 address will be acquired by the associated successfully with BS, IPv6 address will be acquired by the
MS with stateless autoconfiguration or DHCPv6. Note the initiation MS with stateless autoconfiguration or DHCPv6. Note the initiation
skipping to change at page 13, line 36 skipping to change at page 13, line 29
be used within the global end-to-end architecture. But, we don't be used within the global end-to-end architecture. But, we don't
have PKIs across organizations and IPsec isn't integrated with IEEE have PKIs across organizations and IPsec isn't integrated with IEEE
802.16 network mobility management. 802.16 network mobility management.
IEEE 802.16 network threats may be different from IPv6 and IPv6 IEEE 802.16 network threats may be different from IPv6 and IPv6
transition threat models [I-D.ietf-v6ops-security-overview]. It transition threat models [I-D.ietf-v6ops-security-overview]. It
should be also discussed. should be also discussed.
2.6. IPv6 Network Management 2.6. IPv6 Network Management
For IPv6 network management, the necessary instrumentation (such as [IEEE802.16f] includes the management information base for IEEE
MIBs, NetFlow Records, etc) should be available. 802.16 networks. For IPv6 network management, the necessary
instrumentation (such as MIBs, NetFlow Records, etc) should be
available.
Upon entering the network, an MS is assigned three management 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
three different QoS requirements used by different management levels. three different QoS requirements used by different management levels.
The first of these is the basic connection, which is used for the The first of these is the basic connection, which is used for the
transfer of short, time-critical MAC management messages and radio transfer of short, time-critical MAC management messages and radio
link control (RLC) messages. The primary management connection is link control (RLC) messages. The primary management connection is
used to transfer longer, more delay-tolerant messages such as those used to transfer longer, more delay-tolerant messages such as those
used for authentication and connection setup. The secondary used for authentication and connection setup. The secondary
management connection is used for the transfer of standards-based management connection is used for the transfer of standards-based
skipping to change at page 17, line 7 skipping to change at page 16, line 7
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 Please refer to Section 2.5 "IPv6 Security" technology sections for
details. details.
5. Acknowledgements 5. Acknowledgements
This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- This work extends v6ops works on [RFC4779]. We thank all the authors
scenarios]. We thank all the authors of the document. Special of the document. Special thanks are due to Maximilian Riegel, Jonne
thanks are due to Maximilian Riegel, Jonne Soininen, Brian E Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj
Carpenter, Jim Bound, David Johnston, Basavaraj Patil, Byoung-Jo Kim Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa and Jung-Mo Moon for
and Jung-Mo Moon for extensive review of this document. extensive review of this document.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[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.
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", RFC 4779, January 2007.
[I-D.ietf-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-ietf-16ng-ps-goals-00 (work in progress),
October 2006.
6.2. Informative References 6.2. Informative References
[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.
[I-D.ietf-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-ietf-16ng-ps-goals-00 (work in progress),
October 2006.
[I-D.ietf-16ng-ipv6-link-model-analysis] [I-D.ietf-16ng-ipv6-link-model-analysis]
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks", based Networks",
draft-ietf-16ng-ipv6-link-model-analysis-02 (work in draft-ietf-16ng-ipv6-link-model-analysis-02 (work in
progress), January 2007. progress), January 2007.
[I-D.ietf-mipshop-fmipv6-rfc4068bis] [I-D.ietf-mipshop-fmipv6-rfc4068bis]
Koodli, R., "Fast Handovers for Mobile IPv6", Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in
progress), May 2006. progress), May 2006.
skipping to change at page 19, line 10 skipping to change at page 18, line 13
[I-D.ietf-mipshop-fh80216e] [I-D.ietf-mipshop-fh80216e]
Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", draft-ietf-mipshop-fh80216e-01 (work in Networks", draft-ietf-mipshop-fh80216e-01 (work in
progress), January 2007. progress), January 2007.
[I-D.ietf-v6ops-security-overview] [I-D.ietf-v6ops-security-overview]
Davies, E., "IPv6 Transition/Co-existence Security Davies, E., "IPv6 Transition/Co-existence Security
Considerations", draft-ietf-v6ops-security-overview-06 Considerations", draft-ietf-v6ops-security-overview-06
(work in progress), October 2006. (work in progress), October 2006.
[I-D.ietf-v6ops-bb-deployment-scenarios]
Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband
Access Networks",
draft-ietf-v6ops-bb-deployment-scenarios-05 (work in
progress), June 2006.
[I-D.iab-link-encaps] [I-D.iab-link-encaps]
Aboba, B., "Multiple Encapsulation Methods Considered Aboba, B., "Multiple Encapsulation Methods Considered
Harmful", draft-iab-link-encaps-05 (work in progress), Harmful", draft-iab-link-encaps-08 (work in progress),
October 2006. January 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
fixed broadband wireless access systems", October 2004. Fixed Broadband Wireless Access Systems", October 2004.
[IEEE802.16e] [IEEE802.16e]
"IEEE Std. for Local and metropolitan area networks Part "IEEE Standard for Local and Metropolitan Area Networks
16: Air Interface for Fixed and Mobile Broadband Wireless Part 16: Air Interface for Fixed and Mobile Broadband
Access Systems Amendment 2: Physical and Medium Access Wireless Access Systems Amendment 2: Physical and Medium
Control Layers for Combined Fixed and Mobile Operation in Access Control Layers for Combined Fixed and Mobile
Licensed Bands and Corrigendum 1", February 2006. Operation in Licensed Bands and Corrigendum 1",
February 2006.
[IEEE802.16g]
"Draft Amendment to IEEE Standard for Local and
Metropolitan Area Networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems - Management Plane
Procedures and Services", January 2007.
[IEEE802.16f]
"Amendment to IEEE Standard for Local and Metropolitan
Area Networks, Part 16: Air Interface for Fixed Broadband
Wireless Access Systems - Management Information Base",
December 2005.
Authors' Addresses Authors' Addresses
Myung-Ki Shin Myung-Ki Shin
ETRI ETRI
161 Gajeong-dong Yuseng-gu 161 Gajeong-dong Yuseng-gu
Daejeon, 305-350 Daejeon, 305-350
Korea Korea
Phone: +82 42 860 4847 Phone: +82 42 860 4847
skipping to change at page 21, line 7 skipping to change at page 20, 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 Internet Society (2007). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 27 change blocks. 
87 lines changed or deleted 95 lines changed or added

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