draft-ietf-v6ops-802-16-deployment-scenarios-00.txt		draft-ietf-v6ops-802-16-deployment-scenarios-01.txt
	Network Working Group M-K. Shin		Network Working Group M-K. Shin
	Internet-Draft ETRI		Internet-Draft ETRI
	Expires: November 25, 2006 Y-H. Han		Intended status: Informational Y-H. Han
	KUT		Expires: April 4, 2007 KUT
	May 24, 2006		S-E. Kim
			KT
			D. Premec
			Siemens Mobile
			October 1, 2006
	ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks		IPv6 Deployment Scenarios in 802.16(e) Networks
	draft-ietf-v6ops-802-16-deployment-scenarios-00		draft-ietf-v6ops-802-16-deployment-scenarios-01
	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 35		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 November 25, 2006.		This Internet-Draft will expire on April 4, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	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
	skipping to change at page 2, line 12		skipping to change at page 2, line 22
	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. Wireless Broadband Access Network Technologies - IEEE		2. Wireless Broadband Access Network Technologies - IEEE
	802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4		2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4
	2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5		2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5
	2.2.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 7		2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 6
	2.2.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 9		2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 10
	2.2.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 10
	2.2.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 12
	2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13		2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13
	2.4. IPv6 Mobility . . . . . . . . . . . . . . . . . . . . . . 14		2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14
	2.5. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14		2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 14
	2.6. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 15		2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 15
	2.7. IPv6 Network Management . . . . . . . . . . . . . . . . . 15
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 19		6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	6.2. Informative References . . . . . . . . . . . . . . . . . . 19		6.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 22		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Recently, broadband wireless access network is emerging for wireless		Recently, broadband wireless access network is emerging for wireless
	communication for user requirements such as high quality data/voice		communication for user requirements such as high quality data/voice
	service, fast mobility, wide coverage, etc. The IEEE 802.16 Working		service, fast mobility, wide coverage, etc. The IEEE 802.16 Working
	Group develops standards and recommended practices to support the		Group develops standards and recommended practices to support the
	development and deployment of broadband wireless metropolitan area		development and deployment of broadband wireless metropolitan area
	networks.		networks.
	Whereas the existing IEEE 802.16 standard [IEEE802.16] addresses		Whereas the [IEEE802.16] standard addresses fixed wireless
	fixed wireless applications only, the IEEE 802.16(e) standard		applications only, the [IEEE802.16e] standard serves the needs of
	[IEEE802.16e] aims to serve the needs of fixed, nomadic, and fully		fixed, nomadic, and fully mobile networks. It adds mobility support
	mobile networks. It adds mobility support to the original standard		to the original standard so that mobile subscriber stations can move
	so that mobile subscriber stations can move while receiving services.		during services. The standardization of IEEE 802.16e is completed,
	IEEE 802.16e is one of the most promising access technologies which		which plans to support mobility up to speeds of 70~80 mile/h that
	would be applied to the IP-based broadband mobile communication.		will enable the subscribers to carry mobile devices such as PDAs,
			phones, or laptops. IEEE 802.16e is one of the most promising access
	WiMAX Forum is an industrial corporation formed to promote and		technologies which would be applied to the IP-based broadband mobile
	certify compatibility and interoperability of broadband wireless		communication.
	products mainly based on IEEE 802.16. The Network Working Group
	(NWG) of WiMAX Forum is defining the IEEE 802.16 network architecture
	(e.g., IPv4, IPv6, Mobility, interworking with different networks,
	AAA, etc). Similarly, WiBro (Wireless Broadband), Korea effort which
	focuses on the 2.3 GHz spectrum band, is also based on the IEEE
	802.16 and IEEE 802.16e specifications.
	As the deployment of wireless broadband access network progresses,		As the deployment of wireless broadband access network progresses,
	users will be connected to IPv6 networks. While the IEEE 802.16		users will be connected to IPv6 networks. While the IEEE 802.16
	defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16		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. In this document, we will discuss main		deployment is not present. In this document, we will discuss main
	components of IPv6 IEEE 802.16 access network and its differences		components of IPv6 IEEE 802.16 access network and its differences
	from IPv4 IEEE 802.16 networks and how IPv6 is deployed and		from IPv4 IEEE 802.16 networks and how IPv6 is deployed and
	integrated in each of the IEEE 802.16 technologies using tunneling		integrated in each of the IEEE 802.16 technologies using tunneling
	mechanisms and native IPv6.		mechanisms and native IPv6.
	This document extends works of [I-D.ietf-v6ops-bb-deployment-		This document extends works of [I-D.ietf-v6ops-bb-deployment-
	scenarios] and follows the structure and common terminology of the		scenarios] and follows the structure and common terminology of the
	document.		document.
	2. Wireless Broadband Access Network Technologies - IEEE 802.16		2. Wireless Broadband Access Network Technologies - IEEE 802.16
	This section describes the infrastructure that exists today in IEEE		This section describes the infrastructure that is based on IEEE
	802.16 networks providing wireless broadband services to the		802.16 networks providing wireless broadband services to the
	customer. It also describes IPv6 deployment options in these IEEE		customer. It also describes a way to deploy IPv6 over IEEE 802.16
	802.16 networks.		networks.
	2.1. Elements of IEEE 802.16 Networks		2.1. Elements of IEEE 802.16 Networks
	The IEEE 802.11 access network (WLAN) has driven the revolution of		The IEEE 802.11 access network (WLAN) has driven the revolution of
	wireless communication but the more people use it the more its		wireless communication. However, the more people use it the more its
	limitations like short range or lack of mobility support were		limitations such as short range and lack of mobility support arose.
	revealed. Compared with such IEEE 802.11 network, IEEE 802.16		Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced
	supports enhanced features like wider range and mobility. So it is		features such as wider coverage and mobility. So it is expected that
	expected that IEEE 802.16 network could be the next step of IEEE		IEEE 802.16 network could be the next step of IEEE 802.11 network.
	802.11 network.
	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], but the details of IPv6 operations over		outlined in [IEEE802.16], but the details of IPv6 operations over
	IEEE 802.16 are being discussed now.		IEEE 802.16 are being discussed now.
	Here are some of the key elements of IEEE 802.16 networks		Here are some of the key elements of an IEEE 802.16 network:
	MS: Mobile Station. A station in the mobile service intended to be		o MS: Mobile Station. A station in the mobile service intended to
	used while in motion or during halts at unspecified points. A mobile		be used while in motion or during halts at unspecified points. A
	station (MS) is always a subscriber station (SS).		mobile station (MS) is always a subscriber station (SS) which must
			provide mobility function.
	BS: Base Station. A generalized equipment set providing		o BS: Base Station. A generalized equipment set providing
	connectivity, management and control of MS connections. There is a		management and control of MS connections. There is a
	unidirectional mapping between BS and MS medium access control (MAC)		unidirectional mapping between BS and MS medium access control
	peers for the purpose of transporting a service flow's traffic.		(MAC) peers for the purpose of transporting a service flow's
	Connections are identified by a connection identifier (CID) and all		traffic. A connection is identified by a connection identifier
	traffic is carried on a connection. Sometimes there can be		(CID). All traffic is carried on the connection. Sometimes there
	alternative IEEE 802.16 network deployment where a BS is integrated		can be alternative IEEE 802.16 network deployment where a BS is
	with an access router, composing one box in view of implementation.		integrated with an access router, composing one box in view of
			implementation.
	Figure 1 illustrates the key elements of IEEE 802.16 networks.		o AR: Access Router. A generalized equipment set providing IP
			connectivity between BS and IP based network. An AR performs
			first hop routing function to all MS.
			Figure 1 illustrates the key elements of IEEE 802.16(e) networks.
	Customer | Access Provider | Service Provider		Customer | Access Provider | Service Provider
	Premise | | (Backend Network)		Premise | | (Backend Network)
	+-----+ +-----+ +------+ +--------+		+-----+ +----+ +----+ +--------+
	| MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP		| MSs |--(802.16)--| BS |-----| | | Edge | ISP
	+-----+ +-----+ |Router| | Router +==>Network		+-----+ +----+ | AR |---| Router |==>Network
	+--+---+ +--------+		+--| | | (ER) |
	+-----+ +-----+ | | +------+		| +----+ +--------+
	| Mss |--(802.16)--| BS |--------+ +--|AAA |		+-----+ +----+ | | +------+
	+-----+ +-----+ |Server|		| MSs |--(802.16)--| BS |--+ +--|AAA |
			+-----+ +----+ |Server|
	+------+		+------+
	Figure 1: Key Elements of IEEE 802.16(e) Networks		Figure 1: Key Elements of IEEE 802.16(e) Networks
	2.2. Deploying IPv6 in IEEE 802.16 Networks		2.2. Deploying IPv6 in IEEE 802.16 Networks
	IEEE 802.16 supports two modes such as 2-way PMP (Point-to-		[IEEE802.16] specifies two modes for sharing the wireless medium:
	Multipoint) and Mesh topology wireless networks. In this document,		point-to-multipoint (PMP) and mesh (optional). This document only
	we focus on 2-way PMP topology wireless networks.		focuses on PMP mode.
	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 Deployment Model
	IEEE 802.16 BS can offer both fixed communications and mobile
	functions unlike IEEE 802.11. In particular, IEEE 802.16e working
	group standardized such mobility features and the specification of
	IEEE 802.16e provides 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 Deployment 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.
	Many 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, a IEEE 802.16 BS might be used
	just as a wireless hub which a user purchases to build a private
	wireless network in his/her home or laboratory.
	Under 'Hot Zone' use case, a IEEE 802.16 BS will be deployed using an
	Ethernet (IP) backbone rather than a proprietary backend like
	cellular systems. Thus, many IPv6 functionalities will be preserved
	when adopting IPv6 to IEEE 802.16 networks, which brings out many
	research issues [I-D.jee-16ng-problem-statement] [I-D.madanapalli-nd-
	over-802.16-problems].
	Some of the factors that hinder deployment of native IPv6 core		Some of the factors that hinder deployment of native IPv6 core
	protocols include:		protocols are introduced by [I-D.jee-16ng-problem-statement]. The
			summary of them is as follows:
	1. Lacking of Facility for IPv6 Native Multicasting		1. Lacking of Facility for IPv6 Native Multicasting
	IEEE 802.16 is a PMP connection oriented technology without bi-		IEEE 802.16 PMP mode is a connection oriented technology without bi-
	directional native multicast support. IPv6 neighbor discovery		directional native multicast support. IPv6 neighbor discovery
	[RFC2461] supports various functions for the interaction between		[RFC2461] supports various functions for the interaction between
	nodes attached on the same subnet, such as on-link determination and		nodes attached on the same subnet, such as on-link determination and
	address resolution. It is designed with no dependence on a specific		address resolution. It is designed with no dependence on a specific
	link layer technology, but requires that the link layer technology		link layer technology, but requires that the link layer technology
	support native multicast. The specification of IEEE 802.16 provides		support native multicast. This lacking of facility for IPv6 native
	multicast and broadcast services. However, the aim of such services		multicast results in inappropriateness to apply the standard neighbor
	is to transmit IEEE 802.16 MAC management messages, not IP messages.		discover protocol specially regarding, address resolution, router
	This lacking of facility for IPv6 native multicast results in		discovery, stateless auto-configuration and duplicated address
	inappropriateness to apply the standard neighbor discover protocol		detection.
	specially regarding, address resolution, router discovery, stateless
	auto-configuration and duplicated address detection.
	2. Impact of BS on Subnet Model		2. Impact on IPv6 Subnet Model
	IEEE 802.16 is different from existing wireless access technologies		IEEE 802.16 is different from existing wireless access technologies
	such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the		such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the
	encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a		encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a
	complete description of IPv6 operation is not present. IEEE 802.16		complete description of IPv6 operation is not present. IEEE 802.16
	can rather benefit from IETF input and specification to support IPv6		can rather benefit from IETF input and specification to support IPv6
	operation. Especially, BS should look at the classifiers and decide		operation. Especially, BS should look at the classifiers and decide
	where to send the packet, since IEEE 802.16 connection always ends at		where to send the packet, since IEEE 802.16 connection always ends at
	BS, while IPv6 connection terminates at a default router. This		BS, while IPv6 connection terminates at a default router. This
	operation and limitation may be dependent on the given subnet model.		operation and limitation may be dependent on the given subnet model
			[I-D.madanapalli-16ng-subnet-model-analysis].
	Also, we should consider which type of Convergence Sublayer (CS) can		3. Multiple Convergence Sublayers (CS)
	be efficiently used on each subnet models. IEEE 802.16 CS provides
	the tunneling of IP(v6) packets over IEEE 802.16 air-link. The		There are operational complexity problems of IP over 802.16 caused by
	tunnels are identified by the Connection Identifier (CID).		the existence of multiple convergence sublayers [I-D.iab-link-
			encaps]. We should consider which type of Convergence Sublayer (CS)
			can be efficiently used on each subnet models and scenarios. IEEE
			802.16 CS delivers and classifies various kinds of higher layer PDUs
			such as ATM, IPv4 packet and IPv6 packets over radio channel. For
			this purpose, IEEE 802.16 introduces the Connection Identifier (CID).
	Generally, CS performs the following functions in terms of IP packet		Generally, CS performs the following functions in terms of IP packet
	transmission: 1) Receipt of protocol data units (PDUs) from the		transmission: 1) Receipt of protocol data units (PDUs) from the
	higher layer, 2) Performing classification and CID mapping of the		higher layer, 2) Performing classification and CID mapping of the
	PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt		PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt
	of PDUs from the peer MAC SAP. The specification of IEEE 802.16		of PDUs from the peer MAC SAP, and 5) Forwarding the PDUs to the
	defines several CSs for carrying IP packets, but does not provide a		corresponding AR. The specification of IEEE 802.16 defines several
	detailed description of how to carry them. The several CSs are		CSs for carrying IP packets, but does not provide a detailed
	generally classified into two types of CS: IPv6 CS and Ethernet CS.		description of how to carry them. The several CSs are generally
			classified into two types of CS: IPv6 CS and Ethernet CS.
	While deploying IPv6 in the above mentioned approach, there are four		In addition, due to the problems caused by the existence of multiple
	possible typical scenarios as discussed below.		convergence sublayers [I-D.iab-link-encaps], the mobile access
			scenarios need solutions about how roaming will work when forced to
			move from one CS to another. Note that, at this phase this issue is
			the out of scope of this draft. It should be also discussed in 16ng
			WG.
	2.2.1. Scenario A		There are two different deployment scenarios: fixed and mobile
			access. A fixed access scenario substitudes for existing wired-based
			access technologies such as digital subscriber line (xDSL) and cable
			network. This fixed access scenario can provide nomadic access
			within the radio coverages, which is called Hot-zone model. A mobile
			access scenario is for new paradigm for voice, data and video over
			mobile network. This scenario can provide high speed data rate
			equalivent to wire-based Internet as well as mobility function
			equivalent to cellular system. The mobile access scenario can be
			classified into two different IPv6 sunbet models: shared IPv6 prefix
			link model and point-to-point link model.
	Scenario A represents IEEE 802.16 access network deployment where a		2.2.1. Mobile Access Deployment Scenarios
	BS is separated from a router, and a subnet consists of only single
	router and multiple BSs and MSs. Current celluar-like deployment		Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as
	models, WiMax and WiBro, fall within this scenario A.		well as fixed communication. [IEEE802.16e] has been standardized to
			provide mobility features on IEEE 802.16 environments. This use case
			will be implemented only with the licensed spectrum. IEEE 802.16 BS
			might be deployed with a proprietary backend managed by an operator.
			All original IPv6 functionalities [RFC2461], [RFC2462] will not
			survive. Some architectural characteristics of IEEE 802.16 networks
			may affect the detailed operations of NDP [RFC2461].
			There are two possible IPv6 subnet models for mobile access
			deployment scenarios: shared IPv6 prefix link model and point-to-
			point link model [I-D.madanapalli-16ng-subnet-model-analysis]. The
			mobile access deployment models, WiMax and WiBro, fall within this
			deployment model.
			1. Shared IPv6 Prefix Link Model
			This link model represents IEEE 802.16 mobile access network
			deployment where a subnet consists of only single interface of AR and
			multiple MSs. Therefore, all MSs and corresponding interface of AR
			share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be
			different from the interface of AR.
	+-----+		+-----+
	| MS1 |<------+		| MS1 |<-(16)-+
	+-----+ |		+-----+ |
	+-----+ | +-----+ +-----+ +--------+		+-----+ | +-----+ +-----+ +--------+
	| MSs |<------+----| BS1 |---->| AR |----| Edge | ISP		| MS2 |<-(16)-+----| BS1 |--+->| AR |----| Edge | ISP
	+-----+ +-----+ +-----+ | Router +==>Network		+-----+ +-----+ | +-----+ | Router +==>Network
	^ +--------+		| +--------+
	+-----+ +-----+ |		+-----+ +-----+ |
	| Mss |<-----------| BS2 |--------+		| MS3 |<-(16)-+----| BS2 |--+
			+-----+ | +-----+
			+-----+ |
			| MS4 |<-(16)-+
			+-----+
			Figure 2: Shared IPv6 Prefix Link Model
			2. Point-to-Point Link Model
			This link model represents IEEE 802.16 mobile access network
			deployment where a subnet consists of only single AR, BS and MS.
			That is, each connection to a mobile node is treated as a single
			link. Each link between the MS and the AR is allocated a separate,
			unique prefix or unique set of prefixes by the AR. The point-to-
			point link model follows the recommendations of [RFC3314].
			+-----+
			| MS1 |<-(16)---------+
			+-----+ |
			+-----+ +-----+ +-----+ +--------+
			| MS2 |<-(16)------| BS1 |--+->| AR |----| Edge | ISP
			+-----+ +-----+ | +-----+ | Router +==>Network
			| +--------+
			+-----+ +-----+ |
			| MS3 |<-(16)------| BS2 |--+
	+-----+ +-----+		+-----+ +-----+
	<---> IP termination		+-----+ |
			| MS4 |<-(16)---------+
			+-----+
	Figure 2: Scenario A		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, BS (if possible), AR and Edge Router. In		devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE
	this scenario the BS is Layer 3 unaware, so no changes are needed to		802.16 BSs have only MAC and PHY layers without router function and
	support IPv6. However, if IPv4 stack is loaded to them for		operates as a bridge. The BS does not need to support IPv6.
	management and configuration purpose, it is expected that BS should		However, if IPv4 stack is loaded to them for management and
	be upgraded by implementing IPv6 stack, too.		configuration purpose, it is expected that BS should 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 three scenarios below.		options will be equally applied to the other scenario below (Section
			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 using multicast should be properly operated over IEEE		operation should be properly operated over IEEE 802.16 link.
	802.16 link.
	2. IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6		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		server. In this case, the DHCPv6 server would be located in the
	service provider core network and Edge Router would simply act as a		service provider core network and the AR should provide DHCPv6 relay
	DHCP Relay Agent. This option is similar to what we do today in case		agent. This option is similar to what we do today in case of DHCPv4.
	of 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 MS. All MSs attached		single prefix is allocated to all the attached MSs. All MSs attached
	to same AR can be on same IPv6 link.		to same AR can be on same IPv6 link.
	2.2.1.3. IPv6 Control and Data Transport		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
			shared by all the nodes that are attached to the link. In point-to-
			point link model, the AR assigns a unique prefix or set of unique
			prefixes for each MS.
			2.2.1.3. IPv6 Transport
	In a subnet, there are always two underlying links: one is the IEEE		In a subnet, there are always two underlying links: one is the IEEE
	802.16 wireless link between MS and BS, and the other is a wired link		802.16 wireless link between MS and BS, and the other is a wired link
	between BS and AR. Also, there are multiple BSs on the same link.		between BS and AR. The IPv6 packet should be classified by IPv6
			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. So, BS may support IPv6 basic protocols such as ND		IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD
	using multicast functions, or provide some schemes to facilitate the		[RFC2461] does not adapt well to the 802.16 air interface as there is
	stateless auto-configuration. Especially, IEEE 802.16 connection		no native multicast support and when supported consumes air bandwidth
	terminates at BS, not a router. So, BS should look at the		as well as it would have adverse effect on MSs that were in the
	classifiers and decide where to send the packet. In addition, one BS		dormant mode. An optimization, called Relay DAD, may be required to
	can send the packet to other BSs, since multiple BSs are on the same		perform DAD. However, in case of point-to-point link model, DAD is
	link.		easy since each connection to a MN is treated as a unique IPv6 link.
	The operation and transmission methods are being intensively		Note that in this scenario IPv6 CS may be more appropriate than
	discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note		Ethernet CS to transport IPv6 packets, since there are some overhead
	that in this scenario Ethernet CS as well as IPv6 CS may be used to		of Ethernet CS (e.g., Ethernet header) under mobile access
	transport IPv6 packets.		environments .
	Simple or complex network equipments may constitute the underlying		Simple or complex network equipments may constitute the underlying
	wired network between BS and AR. If the IP aware equipments do not		wired network between the AR and the ER. If the IP aware equipments
	support IPv6, the service providers are deploying IPv6-in-IPv4		between the AR and the ER do not support IPv6, the service providers
	tunneling mechanisms to transport IPv6 packets between an AR and an		can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6
	Edge router.		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
	mechanisms as native IPv6 deployment option might be more scalable		mechanisms as native IPv6 deployment option might be more scalable
	and provide required service performance. Tunneling mechanisms		and provide required service performance. Tunneling mechanisms
	should only be used when native IPv6 deployment is not an option.		should only be used when native IPv6 deployment is not an option.
	This can be equally applied to other three scenarios below.		This can be equally applied to other scenario below (Section 2.2.2).
	2.2.1.4. Routing		2.2.1.4. Routing
	In general, the AR is configured with a default route that points to		In general, the MS is configured with a default route that points to
	the Edge router. No routing protocols are needed on these devices		the the AR. Therefore, no routing protocols are needed on the MS.
	which generally have limited resources.		The MS just sends to the AR by default route.
	The Edge Router runs the IGP used in the ISP network such as OSPFv3
	or IS-IS for IPv6. The connected prefixes have to be redistributed.
	Prefix summarization should be done at the Edge Router.
	2.2.2. Scenario B
	Scenario B represents IEEE 802.16 network deployment where a BS is
	separated from a router, there are multiple access routers, and a
	subnet consists of multiple BS and MSs. If 802.16 access networks
	are widely deployed like WLAN, this scenario should be also
	considered. Hot-zone deployment model falls within this scenario B.
	+-----+ +-----+ +-----+ ISP 1
	| MS1 |<-----+ +->| AR1 |----| ER1 |===>Network
	+-----+ | | +-----+ +-----+
	+-----+ | +-----+ |
	| MS2 |<-----+-----| BS1 |--|
	+-----+ +-----+ | +-----+ +-----+ ISP 2
	+->| AR2 |----| ER2 |===>Network
	+-----+ +-----+ | +-----+ +-----+
	| Ms3 |<-----------| BS2 |--+
	+-----+ +-----+
	<---> IP termination
	Figure 3: Scenario B
	2.2.2.1. IPv6 Related Infrastructure Changes
	IPv6 will be deployed in this scenario by upgrading the following
	devices to dual-stack: MS, BS (if possible), AR and Edge Router. In
	this scenario the BS is Layer 3 unaware, so no changes are needed to
	support IPv6. However, if IPv4 stack is loaded to them for
	management and configuration purpose, it is expected that BS should
	be upgraded by implementing IPv6 stack, too.
	2.2.2.2. Addressing
	In this scenario, multiple BSs and MSs form an IPv6 subnet and
	multiple prefixes are allocated to all the attached MS. All MSs
	attached to different BSs under the same AR, can be on same IPv6
	link.
	2.2.2.3. IPv6 Control and Data Transport
	In a subnet, like scenario A, there are always two underlying links:
	one is the IEEE 802.16 wireless link between MS and BS, and the other
	is a wired link between BS and AR. Also, there are multiple BSs on
	the same link.
	If stateless auto-configuration is used to get an IPv6 address,
	considerations on router discovery and DAD operation are the same as
	scenario A.
	The operation and transmission methods are being intensively
	discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note
	that in this scenario Ethernet CS may be more suitable to transport
	IPv6 packets, rather than IPv6 CS, since this scenario requires
	broadcast-like functions (e.g., multi-homing).
	Simple or complex network equipments may constitute the underlying
	wired network between BS and AR. If the IP aware equipments do not
	support IPv6, the service providers are deploying IPv6-in-IPv4
	tunneling mechanisms to transport IPv6 packets between an AR and an
	Edge router.
	2.2.2.4. Routing
	In this scenario, IPv6 multi-homing considerations exist. For
	example, if there exist two routers to support MSs, default router
	must be selected.
	The Edge Router runs the IGP used in the 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		The AR can configure multiple link to ER for network reliability.
	BS is integrated with a router, composing one box in view of		The AR should support IPv6 routing protocol such as OSPFv3 [RFC2740]
	implementation, and a subnet consists of only single BS/router and		or IS-IS for IPv6 when connected to the ER with multiple links.
	multiple MSs.
	+-----+		The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service
	| MS1 |<------+		provider network. The routing information of the ER can be
	+-----+ |		redistributed to the AR. Prefix summarization should be done at the
	+-----+ | +-------+ +--------+		ER.
	| MS2 |<------+--->|BS/AR1 |---------| Edge | ISP
	+-----+ +-------+ | Router +==>Network
	+--------+
	+-----+ +-------+ |
	| Ms3 |<---------->|BS/AR2 |-----------+
	+-----+ +-------+
	<---> IP termination
	Figure 4: Scenario C		2.2.1.5. Mobility
	2.2.3.1. IPv6 Related Infrastructure Changes		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-fmipv6-
			rfc4068bis]) the link mobility information must be available for
			facilitating layer 3 handoff procedure.
	IPv6 will be deployed in this scenario by upgrading the following		Mobile IPv6 defines that movement detection uses Neighbor
	devices to dual-stack: MS, BS/AR and Edge Router.		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.
	2.2.3.2. Addressing		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.
	In this scenario, a single prefix is allocated to all the attached		Also, IEEE 802.16g which is under-developed defines L2 triggers for
	MS. All MSs attached to same BS can be on same IPv6 link.		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.ietf-mipshop-fh80216e].
	2.2.3.3. IPv6 Control and Data Transport		2.2.2. Fixed/Nomadic Deployment Scenarios
	If stateless auto-configuration is used to get an IPv6 address,		The IEEE 802.16 access networks can provide plain Ethernet
	router discovery and DAD operations should be properly operated over		connectivity end-to-end. Wireless DSL deployment model is an example
	IEEE 802.16 link. So, BS/AR should support IPv6 basic protocols such		of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless
	as ND using multicast functions, or provide some schemes to		Internet service providers (Wireless ISPs) have planned to use IEEE
	facilitate the stateless auto-configuration.		802.16 for the purpose of high quality broadband wireless 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, 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.
	The operation and transmission methods are being intensively		Under fixed access model, the IEEE 802.16 BS will be deployed using
	discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note		an IP backbone rather than a proprietary backend like cellular
	that in this scenario Ethernet CS as well as IPv6 CS may be used to		systems. Thus, many IPv6 functionalities such as [RFC2461],
	transport IPv6 packets.		[RFC2462] will be preserved when adopting IPv6 to IEEE 802.16
			devices.
	2.2.3.4. Routing		This scenario also represents IEEE 802.16 network deployment where a
			subnet consists of multiple MSs and multiple interface of the
			multiple BSs. Multiple access routers can exist. There exist
			multiple hosts behind an SS (networks behind an MS may exist). When
			802.16 access networks are widely deployed like WLAN, this case
			should be also considered. Hot-zone deployment model falls within
			this case.
	In general, BS/Router is configured with a default route that points		+-----+ +-----+ +-----+ ISP 1
	to the Edge router. No routing protocols are needed on these devices		| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network
	which generally have limited resources.		+-----+ | | +-----+ +-----+
			+-----+ | +-----+ |
			| SS2 |<-(16)+-----| BS1 |--|
			+-----+ +-----+ | +-----+ +-----+ ISP 2
			+->| AR2 |----| ER2 |===>Network
			+-----+ +-----+ +-----+ | +-----+ +-----+
			|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
			+-----+ +-----+ +-----+
			This network
			behind MS may exist
	The Edge Router runs the IGP used in the SP network such as OSPFv3 or		Figure 4: Fixed/Nomadic Deployment Scenario
	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		While Figure 3 illustrates a generic deployment scenario, the
			following Figure 4 shows in more detail how an existing DSL ISP would
			integrate the 802.16 access network into its existing infrastructure.
	Scenario D represents IEEE 802.16 access network deployment where a		+-----+ +---+ +-----+ +-----+ ISP 1
	BS is integrated with a router, composing one box in view of		| SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network
	implementation. In this scenario, a subnet consists of only single		+-----+ | | b| | +-----+ +-----+
	BS/router and single MS. This scenario mimics the current 3GPP-like		+-----+ | +-----+ |E r| |
	IPv6 deployment model.		| SS2 |<-(16)+-----| BS1 |-----|t i| |
			+-----+ +-----+ |h d|--+
			| g| | +-----+ +-----+ ISP 2
			+-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network
			| SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+
			+-----+ +-----+ +---+ |
			|
			+-----+ +-----+ |
			| TE |<-(DSL)-----|DSLAM|------------+
			+-----+ +-----+
	+-----+		Figure 5: Integration of 802.16 access into DSL infrastructure
	| MS1 |<-------------+
	+-----+ v
	+-----+ +-------+ +--------+
	| MS2 |<---------->|BS/AR1 |---------| Edge | ISP
	+-----+ +-------+ | Router +==>Network
	+--------+
	+-----+ +-------+ |
	| Ms3 |<---------->|BS/AR2 |-----------+
	+-----+ +-------+
	<---> IP termination
	Figure 5: Scenario D		In this approach the 802.16 BS is acting as a DSLAM (Digital
			Subscriber Line Access Multiplexer). On the network side, the BS is
			connected to an Ethernet bridge which can be separate equipment or
			integrated into BRAS (Broadband Remote Access Server).
	2.2.4.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, BS/AR and Edge Router.		devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE
			802.16 BSs have only MAC and PHY layers without router function and
			operates as a bridge. The BS does not need to support IPv6.
			However, if IPv4 stack is loaded to them for management and
			configuration purpose, it is expected that BS should be upgraded by
			implementing IPv6 stack, too.
	2.2.4.2. Addressing		The BRAS in Figure 4 is providing the functionality of the AR. The
			Ethernet bridge is necessary for protecting the BRAS from 802.16 link
			layer peculiarities. The Ethernet bridge relays all traffic received
			through BS to its network side port(s) connected to BRAS. Any
			traffic received from BRAS is relayed to appropriate BS. Since
			802.16 MAC layer has no native support for multicast (and broadcast)
			in the uplink direction, the Ethernet bridge will emulate Ethernet
			level multicast (and broadcast) by relaying the multicast frame
			received from the MS to all of its ports. Ethernet bridge may also
			provide some IPv6 specific functions to increase link efficiency of
			the 802.16 radio link (see Section 2.2.2.3).
	In this case, if stateless auto-configuration is used, 3GPP-like IPv6		2.2.2.2. Addressing
	addressing scheme [RFC 3314] can be 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.2.4.3. IPv6 Control and Data Transport		One or more IPv6 prefixes can be shared to all the attached MSs.
			Prefix delegation can be required since networks can exist behind SS.
	In this scenario, IEEE 802.16 connection and IPv6 termination point		2.2.2.3. IPv6 Transport
	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		Note that in this scenario Ethernet CS may be more appropriate than
	adoption. For example, DAD operation is not needed since each MS has		IPv6 CS to transport IPv6 packets, since the scenario need to support
	only a well-known neighbor, a router. The operation and transmission		plain Ethernet connectivity end-to-end. However, the IPv6 CS can
	methods are being intensively discussed in other documents [I-D.shin-		also be supported. Every MS and the BS has the Ethernet type MAC
	16ng-ipv6-transmission].		address. If the MS is using IP CS, then the BS needs to take care of
			the Ethernet header. In the upstream direction, the BS will need to
			generate an appropriate Ethernet header and prepend it to the IP
			datagram. In the downstream direction, the BS will use the
			destination address from the Ethernet header to identify the MS and
			then it will strip the Ethernet header before relaying the IP
			datagram over the 802.16 MAC connection. Ethernet bridge may provide
			implementation of authoritative address cache and Relay DAD.
			Authoritative address cache is a mapping between the IPv6 address and
			the MAC addresses of all attached MSs.
	Note that in this scenario IPv6 CS type may be more suitable to		The bridge builds its authoritative address cache by parsing the IPv6
	transport IPv6 packets rather than Ethernet CS type since broadcast-		Neighbor Discovery messages used during address configuration (DAD).
	like functions are not required.		Relay DAD means that the Neighbor Solicitation message used in DAD
			process will be relayed only to the MS which already has configured
			the solicited address as its own address (if such MS exist at all).
	2.2.4.4. Routing		2.2.2.4. Routing
	In general, the access router is configured with a default route that		In this scenario, IPv6 multi-homing considerations exist. For
	points to the Edge Router. No routing protocols are needed on these		example, if there exist two routers to support MSs, default router
	devices which generally have limited resources.		must be selected.
	The Edge Router runs the IGP used in the service provider network		The Edge Router runs the IGP used in the SP network such as OSPFv3
	such as OSPFv3 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
			No mobility functions are supported in fixed access scenario.
			However, mobility can support in the radio coverage without any
			mobility protocol like WLAN technology. Therefore, a user can access
			Internet nomadically in the coverage.
	2.3. IPv6 Multicast		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. 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. For MBS how this mapping will happen is
			not clear, so MBS discussions have been postponed in WiMax for now.
			Note that it should be intensively researched later, since MBS will
			be one of the killer services in IEEE 802.16 networks.
	In order to support multicast services in IEEE 802.16, Multicast		In order to support multicast services in IEEE 802.16, Multicast
	Listener Discovery (MLD) [RFC2710] must be supported between the MS		Listener Discovery (MLD) [RFC2710] must be supported between the MS
	and BS/Router. Also, the inter-working with IP multicast protocols		and AR. Also, the inter-working with IP multicast protocols and
	and Multicast and Broadcast Service (MBS) should be considered.		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 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		MBS defines Multicast and Broadcast Services, but actually, MBS seems
	to be a broadcast service, not multicasting. MBS adheres to		to be a broadcast service, not multicasting. MBS adheres to
	broadcast services, while traditional IP multicast schemes define		broadcast services, while traditional IP multicast schemes define
	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.
	Note that it should be intensively researched later, since MBS will		2.4. IPv6 QoS
	be one of the killer services in IEEE 802.16 networks.
	2.4. IPv6 Mobility
	As for mobility management, the movement between BSs is handled by
	Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in
	certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the
	link mobility information must be available for facilitating layer 3
	handoff procedure.
	Mobile IPv6 defines that movement detection uses Neighbor
	Unreachability Detection 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, if a BS is integrated
	with a AR.
	In addition, IEEE 802.16e has facilities in determining whether the
	change of MS's IP address is required during the handoff. Therefore,
	Mobile IPv6 can get a hint from such low-layer facilities, and
	conduct its Layer 3 mobility protocol only when it is needed. Though
	a handoff has occurred, an additional router discovery procedure is
	not required in case of intra-subnet handoff. Also, faster handoff
	may be occurred by the L2 trigger in case of inter-subnet handoff.
	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. IEEE 802.16g which is
	under-developed defines L2 triggers for IEEE 802.16 link status such
	as link-up, link-down, handoff-start. These L2 triggers may make
	Mobile IPv6 procedure more efficient and faster.
	This issue is also being discussed in [I-D.ietf-mipshop-fh80216e].
	2.5. 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 QoS has different semantics with IP QoS (e.g.,
	diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS		diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS
	parameters of the service flow associated with that connection. In		parameters of the service flow associated with that connection. In
	order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label		order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label
	for IPv6) mapping to IEEE 802.16 link specifics should be provided.		for IPv6) mapping to IEEE 802.16 link specifics should be provided.
	2.6. 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 MSs. If		by the BS to the AAA server. The AAA server authenticates the MSs
	an MS is once authenticated and associated successfully with BS, an		and once authenticated. When an MS is once authenticated and
	IPv6 address will be acquired by the MS. Note the initiation and		associated successfully with BS, IPv6 address will be acquired by the
	authentication process is the same as used in IPv4.		MS with stateless autoconfiguration or DHCPv6. Note the initiation
			and authentication process is the same as used in IPv4.
	IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may		IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may
	be used within the global end-to-end architecture. But, we don't		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.7. IPv6 Network Management		2.6. IPv6 Network Management
	For IPv6 network management, the necessary instrumentation (such as		For IPv6 network management, the necessary instrumentation (such as
	MIBs, NetFlow Records, etc) should be available.		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 message 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
	management messages such as Dynamic Host Configuration Protocol		management messages such as Dynamic Host Configuration Protocol
	(DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network		(DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network
	Management Protocol (SNMP).		Management Protocol (SNMP).
			IPv6 based IEEE 802.16 network can be managed by IPv4 or IPv6 when
			network elements are implemented dual stak. For example, network
			management system (NMS) can send SNMP message by IPv4 with IPv6
			related object identifier. Also, an NMS can use IPv6 for SNMP
			request and response including IPv4 related OID.
	3. IANA Considerations		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 sec 2.6 "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 [I-D.ietf-v6ops-bb-deployment-
	scenarios]. We thank all the authors of the document.		scenarios]. We thank all the authors of the document. Special
			thanks are due to Maximilian Riegel, Jonne Soininen, Brian E
			Carpenter, Jim Bound, and Jung-Mo Moon for extensive review of this
			document.
	6. References		6. References
	6.1. Normative 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		[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.
	[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		[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.
	6.2. Informative References		[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
			RFC 2740, December 1999.
	[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.		6.2. Informative References
	Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
	Second and Third Generation Cellular Hosts", RFC 3316,
	April 2003.
	[I-D.ietf-mipshop-fast-mipv6]		[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
	Koodli, R., "Fast Handovers for Mobile IPv6",		Generation Partnership Project (3GPP) Standards",
	draft-ietf-mipshop-fast-mipv6-03 (work in progress),		RFC 3314, September 2002.
	October 2004.
	[I-D.madanapalli-nd-over-802.16-problems]		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	Madanapalli, S., "IPv6 Neighbor Discovery over 802.16:		in IPv6", RFC 3775, June 2004.
	Problems and Goals",
	draft-madanapalli-nd-over-802.16-problems-00 (work in
	progress), December 2005.
	[I-D.mandin-ip-over-80216-ethcs]		[I-D.jee-16ng-problem-statement]
	Mandin, J., "Transport of IP over 802.16",		Jee, J., "16ng Problem Statement",
	draft-mandin-ip-over-80216-ethcs-00 (work in progress),		draft-jee-16ng-problem-statement-02 (work in progress),
	October 2005.		October 2005.
			[I-D.madanapalli-16ng-subnet-model-analysis]
			Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
			based Networks",
			draft-madanapalli-16ng-subnet-model-analysis-01 (work in
			progress), September 2006.
			[I-D.ietf-mipshop-fmipv6-rfc4068bis]
			Koodli, R., "Fast Handovers for Mobile IPv6",
			draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in
			progress), May 2006.
			[I-D.ietf-mipshop-fh80216e]
			Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
			Networks", draft-ietf-mipshop-fh80216e-00 (work in
			progress), April 2006.
	[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-04		Considerations", draft-ietf-v6ops-security-overview-05
	(work in progress), March 2006.		(work in progress), September 2006.
	[I-D.ietf-v6ops-bb-deployment-scenarios]		[I-D.ietf-v6ops-bb-deployment-scenarios]
	Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband		Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband
	Access Networks",		Access Networks",
	draft-ietf-v6ops-bb-deployment-scenarios-04 (work in		draft-ietf-v6ops-bb-deployment-scenarios-05 (work in
	progress), October 2005.		progress), June 2006.
	[I-D.shin-16ng-ipv6-transmission]		[I-D.iab-link-encaps]
	Shin, M. and H. Jang, "Transmission of IPv6 Packets over		Aboba, B., "Multiple Encapsulation Methods Considered
	IEEE 802.16", draft-shin-16ng-ipv6-transmission-00 (work		Harmful", draft-iab-link-encaps-02 (work in progress),
	in progress), February 2006.		August 2006.
	[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 Std. for Local and metropolitan area networks Part
	16: Air Interface for Fixed and Mobile Broadband Wireless		16: Air Interface for Fixed and Mobile Broadband Wireless
	Access Systems Amendment 2: Physical and Medium Access		Access Systems Amendment 2: Physical and Medium Access
	skipping to change at page 22, line 5		skipping to change at page 21, line 24
	Email: myungki.shin@gmail.com		Email: myungki.shin@gmail.com
	Youn-Hee Han		Youn-Hee Han
	KUT		KUT
	Gajeon-Ri 307 Byeongcheon-Myeon		Gajeon-Ri 307 Byeongcheon-Myeon
	Cheonan-Si Chungnam Province, 330-708		Cheonan-Si Chungnam Province, 330-708
	Korea		Korea
	Email: yhhan@kut.ac.kr		Email: yhhan@kut.ac.kr
	Intellectual Property Statement		Sang-Eon Kim
			KT
			17 Woomyeon-dong, Seocho-gu
			Seoul, 137-791
			Korea
			Email: sekim@kt.co.kr
			Domagoj Premec
			Siemens Mobile
			Heinzelova 70a
			10010 Zagreb
			Croatia
			Email: domagoj.premec@siemens.com
			Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 22, line 29		skipping to change at page 22, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		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		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 95 change blocks.
	452 lines changed or deleted		455 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/