draft-ietf-v6ops-802-16-deployment-scenarios-07.txt		rfc5181.txt
	Network Working Group M-K. Shin, Ed.		Network Working Group M-K. Shin, Ed.
	Internet-Draft ETRI		Request for Comments: 5181 ETRI
	Intended status: Informational Y-H. Han		Category: Informational Y-H. Han
	Expires: July 31, 2008 KUT		KUT
	S-E. Kim		S-E. Kim
	KT		KT
	D. Premec		D. Premec
	Siemens Mobile		Siemens Mobile
	January 28, 2008
	IPv6 Deployment Scenarios in 802.16 Networks		IPv6 Deployment Scenarios in 802.16 Networks
	draft-ietf-v6ops-802-16-deployment-scenarios-07
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 31, 2008.
	Copyright Notice		Status of This Memo
	Copyright (C) The IETF Trust (2008).		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Abstract		Abstract
	This document provides a detailed description of IPv6 deployment and		This document provides a detailed description of IPv6 deployment and
	integration methods and scenarios in wireless broadband access		integration methods and scenarios in wireless broadband access
	networks in coexistence with deployed IPv4 services. In this		networks in coexistence with deployed IPv4 services. In this
	document we will discuss main components of IPv6 IEEE 802.16 access		document, we will discuss the main components of IPv6 IEEE 802.16
	networks and their differences from IPv4 IEEE 802.16 networks and how		access networks and their differences from IPv4 IEEE 802.16 networks
	IPv6 is deployed and integrated in each of the IEEE 802.16		and how IPv6 is deployed and integrated in each of the IEEE 802.16
	technologies.		technologies.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3		2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3
	2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3		2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3
	2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4		2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 3
	2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5		2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 4
	2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 8		2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 8
	2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11		2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 10
	2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 11		2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 11
	2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 12		2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 11
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 13		5.2. Informative References . . . . . . . . . . . . . . . . . . 13
	6.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 17
	1. Introduction		1. Introduction
	As the deployment of IEEE 802.16 access networks progresses, users		As the deployment of IEEE 802.16 access networks progresses, users
	will be connected to IPv6 networks. While the IEEE 802.16 standard		will be connected to IPv6 networks. While the IEEE 802.16 standard
	defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16		defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16
	MAC payload, a complete description of IPv4/IPv6 operation and		Media Access Control (MAC) payload, a complete description of IPv4/
	deployment is not present. The IEEE 802.16 standards are limited to		IPv6 operation and deployment is not present. The IEEE 802.16
	L1 and L2, so they may be used within any number of IP network		standards are limited to L1 and L2, so they may be used within any
	architectures and scenarios. In this document, we will discuss main		number of IP network architectures and scenarios. In this document,
	components of IPv6 IEEE 802.16 access networks and their differences		we will discuss the main components of IPv6 IEEE 802.16 access
	from IPv4 IEEE 802.16 networks and how IPv6 is deployed and		networks and their differences from IPv4 IEEE 802.16 networks and how
	integrated in each of the IEEE 802.16 technologies.		IPv6 is deployed and integrated in each of the IEEE 802.16
			technologies.
	This document extends the work of [RFC4779] and follows the structure		This document extends the work of [RFC4779] and follows the structure
	and common terminology of that document.		and common terminology of that document.
	1.1. Terminology		1.1. Terminology
	The IEEE 802.16 related terminologies in this document are to be		The IEEE 802.16-related terminologies in this document are to be
	interpreted as described in [I-D.ietf-16ng-ps-goals].		interpreted as described in [RFC5154].
	o Subscriber Station (SS): An end-user equipment that provides		o Subscriber Station (SS): An end-user equipment that provides
	connectivity to the 802.16 networks. It can be either fixed/		connectivity to the 802.16 networks. It can be either fixed/
	nomadic or mobile equipment. In mobile environment, SS represents		nomadic or mobile equipment. In a mobile environment, SS
	the Mobile Subscriber Station (MS) introduced in [IEEE802.16e].		represents the Mobile Subscriber Station (MS) introduced in
			[IEEE802.16e].
	o Base Station (BS): A generalized equipment set providing		o Base Station (BS): A generalized equipment set providing
	connectivity, management, and control between the subscriber		connectivity, management, and control between the subscriber
	station and the 802.16 networks.		station and the 802.16 networks.
	o Access Router (AR): An entity that performs an IP routing function		o Access Router (AR): An entity that performs an IP routing function
	to provide IP connectivity for subscriber station (SS or MS).		to provide IP connectivity for a subscriber station (SS or MS).
	o Connection Identifier (CID): A 16-bit value that identifies a		o Connection Identifier (CID): A 16-bit value that identifies a
	connection to equivalent peers in the 802.16 MAC of the SS(MS) and		connection to equivalent peers in the 802.16 MAC of the SS(MS) and
	BS.		BS.
	o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS specific
			o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS-specific
	part of the Packet CS defined in 802.16 STD.		part of the Packet CS defined in 802.16 STD.
	o IPv6 CS (Convergence Sublayer): IPv6 specific subpart of the
			o IPv6 CS (Convergence Sublayer): IPv6-specific subpart of the
	Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.		Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.
	2. Deploying IPv6 in IEEE 802.16 Networks		2. Deploying IPv6 in IEEE 802.16 Networks
	2.1. Elements of IEEE 802.16 Networks		2.1. Elements of IEEE 802.16 Networks
	[IEEE 802.16e] is an air interface for fixed and mobile broadband		[IEEE 802.16e] is an air interface for fixed and mobile broadband
	wireless access systems. [IEEE 802.16] only specifies the		wireless access systems. [IEEE802.16] only specifies the convergence
	convergence sublayers and the ability to transport IP over the air		sublayers and the ability to transport IP over the air interface.
	interface. The details of IPv6 (and IPv4) operations over IEEE		The details of IPv6 (and IPv4) operations over IEEE 802.16 are
	802.16 are defined in the 16ng WG. The IPv6 over IPCS definition is		defined in the 16ng WG. The IPv6 over IPv6 CS definition is already
	already an approved specification [I-D.ietf-16ng-ipv6-over-ipv6cs].		an approved specification [RFC5121]. IP over Ethernet CS in IEEE
			802.16 is defined in [IP-ETHERNET].
	IP over Ethernet CS in IEEE 802.16 is defined in
	[I-D.ietf-16ng-ip-over-ethernet-over-802.16].
	Figure 1 illustrates the key elements of typical mobile 802.16		Figure 1 illustrates the key elements of typical mobile 802.16
	deployments.		deployments.
	Customer | Access Provider | Service Provider		Customer | Access Provider | Service Provider
	Premise | | (Backend Network)		Premise | | (Backend Network)
	+-----+ +----+ +----+ +--------+		+-----+ +----+ +----+ +--------+
	| SSs |--(802.16)--| BS |-----| | | Edge | ISP		| SSs |--(802.16)--| BS |-----| | | Edge | ISP
	+-----+ +----+ | AR |---| Router |==>Network		+-----+ +----+ | AR |---| Router |==>Network
	skipping to change at page 4, line 33		skipping to change at page 3, line 42
	Figure 1: Key Elements of IEEE 802.16(e) Networks		Figure 1: Key Elements of IEEE 802.16(e) Networks
	2.2. Scenarios and IPv6 Deployment		2.2. Scenarios and IPv6 Deployment
	[IEEE802.16] specifies two modes for sharing the wireless medium:		[IEEE802.16] specifies two modes for sharing the wireless medium:
	point-to-multipoint (PMP) and mesh (optional). This document only		point-to-multipoint (PMP) and mesh (optional). This document only
	focuses on the PMP mode.		focuses on the PMP mode.
	Some of the factors that hinder deployment of native IPv6 core		Some of the factors that hinder deployment of native IPv6 core
	protocols are already introduced by [I-D.ietf-16ng-ps-goals].		protocols are already introduced by [RFC5154].
	There are two different deployment scenarios: fixed and mobile access		There are two different deployment scenarios: fixed and mobile access
	deployment scenarios. A fixed access scenario substitutes for		deployment scenarios. A fixed access scenario substitutes for
	existing wired-based access technologies such as digital subscriber		existing wired-based access technologies such as digital subscriber
	lines (xDSL) and cable networks. This fixed access scenario can		lines (xDSL) and cable networks. This fixed access scenario can
	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 exists for the new paradigm		the Hot-zone model. A mobile access scenario exists for the new
	of transmitting voice, data and video over mobile networks. This		paradigm of transmitting voice, data, and video over mobile networks.
	scenario can provide high speed data rates equivalent to the wire-		This scenario can provide high-speed data rates equivalent to the
	based Internet as well as mobility functions equivalent to cellular		wire-based Internet as well as mobility functions equivalent to
	systems. There are the different IPv6 impacts on convergence		cellular systems. There are the different IPv6 impacts on
	sublayer type, link model, addressing, mobility, etc. between fixed		convergence sublayer type, link model, addressing, mobility, etc.
	and mobile access deployment scenarios. The details will be		between fixed and mobile access deployment scenarios. The details
	discussed below. The mobile access scenario can be classified into		will be discussed below. The mobile access scenario can be
	two different IPv6 link models: shared IPv6 prefix link model and		classified into two different IPv6 link models: shared IPv6 prefix
	point-to-point link model.		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, the IEEE 802.16 BS can provide mobility functions		Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions
	and fixed communications. [IEEE802.16e] has been standardized to		and fixed communications. [IEEE802.16e] has been standardized to
	provide mobility features on IEEE 802.16 environments. IEEE 802.16		provide mobility features on IEEE 802.16 environments. IEEE 802.16
	BS might be deployed with a proprietary backend managed by an		BS might be deployed with a proprietary backend managed by an
	operator.		operator.
	There are two possible IPv6 link models for mobile access deployment		There are two possible IPv6 link models for mobile access deployment
	skipping to change at page 5, line 43		skipping to change at page 5, line 4
	+-----+ | +-----+ +--------+		+-----+ | +-----+ +--------+
	+->| AR |----| Edge | ISP		+->| AR |----| Edge | ISP
	+-----+ | +-----+ | Router +==>Network		+-----+ | +-----+ | Router +==>Network
	| MS3 |<-(16)-+ +-----+ | +--------+		| MS3 |<-(16)-+ +-----+ | +--------+
	+-----+ +----| BS2 |--+		+-----+ +----| BS2 |--+
	+-----+ | +-----+		+-----+ | +-----+
	| MS4 |<-(16)-+		| MS4 |<-(16)-+
	+-----+		+-----+
	Figure 2: Shared IPv6 Prefix Link Model		Figure 2: Shared IPv6 Prefix Link Model
	(2) Point-to-Point Link Model		(2) Point-to-Point Link Model
	This link model represents IEEE 802.16 mobile access network		This link model represents IEEE 802.16 mobile access network
	deployments where a subnet consists of only single AR, BS and MS.		deployments where a subnet consists of only a single AR, BS, and MS.
	That is, each connection to a mobile node is treated as a single		That is, each connection to a mobile node is treated as a single
	link. Each link between the MS and the AR is allocated a separate,		link. Each link between the MS and the AR is allocated a separate,
	unique prefix or unique set of prefixes by the AR. The point-to-		unique prefix or a set of unique prefixes by the AR. The point-to-
	point link model follows the recommendations of [RFC3314].		point link model follows the recommendations of [RFC3314].
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| MS1 |<-(16)------| |---->| |		| MS1 |<-(16)------| |---->| |
	+-----+ | BS1 | | |		+-----+ | BS1 | | |
	+-----+ | | | | +--------+		+-----+ | | | | +--------+
	| MS2 |<-(16)------| |---->| |----| Edge | ISP		| MS2 |<-(16)------| |---->| |----| Edge | ISP
	+-----+ +-----+ | | | Router +==>Network		+-----+ +-----+ | | | Router +==>Network
	| AR | +--------+		| AR | +--------+
	+-----+ +-----+ | |		+-----+ +-----+ | |
	| MS3 |<-(16)------| |---->| |		| MS3 |<-(16)------| |---->| |
	+-----+ | BS2 | | |		+-----+ | BS2 | | |
	+-----+ | | | |		+-----+ | | | |
	| 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 functionality and		BSs have only MAC and PHY (Physical Layer) layers without router
	operate as a bridge. The BS should support IPv6 classifiers as		functionality and operate as a bridge. The BS should support IPv6
	specified in [IEEE802.16].		classifiers as specified in [IEEE802.16].
	2.2.1.2. Addressing		2.2.1.2. Addressing
	An IPv6 MS has two possible options to get an IPv6 address. These		An IPv6 MS has two possible options to get an IPv6 address. These
	options will be equally applied to the other scenario below (Section		options will be equally applied to the other scenario below (Section
	2.2.2).		2.2.2).
	(1) An IPv6 MS can get the IPv6 address from an access router using		(1) An IPv6 MS can get the IPv6 address from an access router using
	stateless auto-configuration. In this case, router discovery and DAD		stateless auto-configuration. In this case, router discovery and
	operation should be properly operated over an IEEE 802.16 link.		Duplicate Address Detection (DAD) operation should be properly
			operated over an IEEE 802.16 link.
	(2) An IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6		(2) An IPv6 MS can use Dynamic Host Configuration Protocol for IPv6
	server. In this case, the DHCPv6 server would be located in the		(DHCPv6) to get an IPv6 address from the DHCPv6 server. In this
	service provider core network and the AR should provide a DHCPv6		case, the DHCPv6 server would be located in the service provider core
	relay agent. This option is similar to what we do today in case of		network, and the AR should provide a DHCPv6 relay agent. This option
	DHCPv4.		is similar to what we do today in case of DHCPv4.
	In this scenario, a router and multiple BSs form an IPv6 subnet and a		In this scenario, a router and multiple BSs form an IPv6 subnet, and
	single prefix is allocated to all the attached MSs. All MSs attached		a single prefix is allocated to all the attached MSs. All MSs
	to same AR can be on the same IPv6 link.		attached to the same AR can be on the same IPv6 link.
	As for the prefix assignment, in case of the shared IPv6 prefix link		As for the prefix assignment, in the case of the shared IPv6 prefix
	model, one or more IPv6 prefixes are assigned to the link and hence		link model, one or more IPv6 prefixes are assigned to the link and
	shared by all the nodes that are attached to the link. In the point-		are hence shared by all the nodes that are attached to the link. In
	to-point link model, the AR assigns a unique prefix or a set of		the point-to-point link model, the AR assigns a unique prefix or a
	unique prefixes for each MS. Prefix delegation can be required if		set of unique prefixes for each MS. Prefix delegation can be
	networks exist behind an MS.		required if networks exist behind an MS.
	2.2.1.3. IPv6 Transport		2.2.1.3. IPv6 Transport
	In an IPv6 subnet, there are always two underlying links: one is the		In an IPv6 subnet, there are always two underlying links: one is the
	IEEE 802.16 wireless link between the MS and BS, and the other is a		IEEE 802.16 wireless link between the MS and BS, and the other is a
	wired link between the BS and AR.		wired link between the BS and AR.
	IPv6 packets can be sent and received via the IP specific part of the		IPv6 packets can be sent and received via the IP-specific part of the
	packet convergence sublayer. The Packet CS is used for the transport		packet convergence sublayer. The Packet CS is used for the transport
	of packet based protocols which include Ethernet and Internet		of packet-based protocols, which include Ethernet and Internet
	Protocol (IPv4 and IPv6). Note that in this scenario IPv6 CS may be		Protocol (IPv4 and IPv6). Note that in this scenario, IPv6 CS may be
	more appropriate than Ethernet CS to transport IPv6 packets, since		more appropriate than Ethernet CS to transport IPv6 packets, since
	there is some overhead of Ethernet CS (e.g., Ethernet header) under		there is some overhead of Ethernet CS (e.g., Ethernet header) under
	mobile access environments. However, when PHS (Payload Header		mobile access environments. However, when PHS (Payload Header
	Suppression) is deployed it mitigates this overhead through the		Suppression) is deployed, it mitigates this overhead through the
	compression of packet headers. The details of IPv6 operations over		compression of packet headers. The details of IPv6 operations over
	the IP specific part of the packet CS defined in		the IP-specific part of the packet CS are defined in [RFC5121].
	[I-D.ietf-16ng-ipv6-over-ipv6cs].
	Simple or complex network equipment may constitute the underlying		Simple or complex network equipment may constitute the underlying
	wired network between the AR and the ER. If the IP-aware equipment		wired network between the AR and the ER. If the IP-aware equipment
	between the AR and the ER does not support IPv6, the service		between the AR and the ER does not support IPv6, the service
	providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport		providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport
	IPv6 packets between the AR and the ER.		IPv6 packets between the AR and the ER.
	The service providers are deploying tunneling mechanisms to transport		The service providers are deploying tunneling mechanisms to transport
	IPv6 over their existing IPv4 networks as well as deploying native		IPv6 over their existing IPv4 networks as well as deploying native
	IPv6 where possible. Native IPv6 should be preferred over tunneling		IPv6 where possible. Native IPv6 should be preferred over tunneling
	skipping to change at page 7, line 45		skipping to change at page 7, line 11
	and provide the required service performance. Tunneling mechanisms		and provide the 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 scenarios below (Section 2.2.2).		This can be equally applied to other scenarios below (Section 2.2.2).
	2.2.1.4. Routing		2.2.1.4. Routing
	In general, the MS is configured with a default route that points to		In general, the MS is configured with a default route that points to
	the AR. Therefore, no routing protocols are needed on the MS. The		the AR. Therefore, no routing protocols are needed on the MS. The
	MS just sends to the AR using the default route.		MS just sends to the AR using the default route.
	The AR can configure multiple links to ER for network reliability.		The AR can configure multiple links to the ER for network
	The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740]		reliability. The AR should support IPv6 routing protocols such as
	or IS-IS for IPv6 when connected to the ER with multiple links.		OSPFv3 [RFC2740] or Intermediate System to Intermediate System
			(IS-IS) for IPv6 when connected to the ER with multiple links.
	The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service		The ER runs the Interior Gateway Protocol (IGP) such as OSPFv3 or
	provider network. The routing information of the ER can be		IS-IS for IPv6 in the service provider network. The routing
	redistributed to the AR. Prefix summarization should be done at the		information of the ER can be redistributed to the AR. Prefix
	ER.		summarization should be done at the ER.
	2.2.1.5. Mobility		2.2.1.5. Mobility
	There are two types of handovers for the IEEE 802.16e networks: link		There are two types of handovers for the IEEE 802.16e networks: link
	layer handover and IP layer handover. In a link layer handover, BSs		layer handover and IP layer handover. In a link layer handover, BSs
	involved in the handover reside in the same IP subnet. A MS only		involved in the handover reside in the same IP subnet. An MS only
	needs to re-establish a link layer connection with a new BS without		needs to reestablish a link layer connection with a new BS without
	changing its IP configuration, such as its IP address, default		changing its IP configuration, such as its IP address, default
	router, on-link prefix, etc. The link layer handover in IEEE 802.16e		router, on-link prefix, etc. The link layer handover in IEEE 802.16e
	is by nature a hard handover since the MS has to cut off the		is by nature a hard handover since the MS has to cut off the
	connection with the current BS at the beginning of the handover		connection with the current BS at the beginning of the handover
	process and cannot resume communication with the new BS until the		process and cannot resume communication with the new BS until the
	handover completes [IEEE802.16e]. In an IP layer handover, the BSs		handover completes [IEEE802.16e]. In an IP layer handover, the BSs
	involved reside in different IP subnets, or in different networks.		involved reside in different IP subnets, or in different networks.
	Thus, in an IP layer handover, a MS needs to establish both a new		Thus, in an IP layer handover, an MS needs to establish both a new
	link layer connection, as in a link layer handover, and a new IP		link layer connection, as in a link layer handover, and a new IP
	configuration to maintain connectivity.		configuration to maintain connectivity.
	IP layer handover for MSs is handled by Mobile IPv6 [RFC3775].		IP layer handover for MSs is handled by Mobile IPv6 [RFC3775].
	Mobile IPv6 defines that movement detection uses Neighbor		Mobile IPv6 defines that movement detection uses Neighbor
	Unreachability Detection to detect when the default router is no		Unreachability Detection to detect when the default router is no
	longer bidirectionally reachable, in which case the mobile node must		longer bidirectionally reachable, in which case the mobile node must
	discover a new default router. Periodic Router Advertisements for		discover a new default router. Periodic Router Advertisements for
	reachability and movement detection may be unnecessary because the		reachability and movement detection may be unnecessary because the
	IEEE 802.16 MAC provides the reachability by its ranging procedure		IEEE 802.16 MAC provides the reachability by its ranging procedure
	and the movement detection by the Handoff procedure.		and the movement detection by the Handoff procedure.
	Mobile IPv6 alone will not solve the handover latency problem for the		Mobile IPv6 alone will not solve the handover latency problem for the
	IEEE 802.16e networks. To reduce or eliminate packet loss and to		IEEE 802.16e networks. To reduce or eliminate packet loss and to
	reduce the handover delay in Mobile IPv6, therefore, Fast Handover		reduce the handover delay in Mobile IPv6, therefore, Fast Handover
	for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with		for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with
	MIPv6. To perform predictive packet forwarding, the FMIPv6's IP		MIPv6. To perform predictive packet forwarding, the FMIPv6's IP
	layer assumes the presence of handover-related triggers delivered by		layer assumes the presence of handover-related triggers delivered by
	the IEEE 802.16 MAC layers. Thus, there is a need for cross-layering		the IEEE 802.16 MAC layers. Thus, there is a need for cross-layering
	design to support proper behavior of the FMIPv6 solution. This issue		design to support proper behavior of the FMIPv6 solution. This issue
	is also being discussed in [I-D.ietf-mipshop-fh80216e].		is also discussed in [MIPSHOP-FH80216E].
	Also, [IEEE802.16g] defines L2 triggers for link status such as		Also, [IEEE802.16g] defines L2 triggers for link status such as
	link-up, link-down, handoff-start. These L2 triggers may make the		link-up, link-down, and handoff-start. These L2 triggers may make
	Mobile IPv6 or FMIPv6 procedure more efficient and faster.		the Mobile IPv6 or FMIPv6 procedure more efficient and faster.
			In addition, due to the problems caused by the existence of multiple
			convergence sublayers [RFC4840], the mobile access scenarios need
			solutions about how roaming will work when forced to move from one CS
			to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase,
			this issue is the out of scope of this document.
	2.2.2. Fixed/Nomadic Deployment Scenarios		2.2.2. Fixed/Nomadic Deployment Scenarios
	The IEEE 802.16 access networks can provide plain Ethernet end-to-end		The IEEE 802.16 access networks can provide plain Ethernet end-to-end
	connectivity. This scenario represents deployment model using		connectivity. This scenario represents a deployment model using
	Ethernet CS. Wireless DSL deployment model is an example of a fixed/		Ethernet CS. A wireless DSL deployment model is an example of a
	nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet		fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet
	service providers (Wireless ISPs) have planned to use IEEE 802.16 for		service providers (wireless ISPs) have planned to use IEEE 802.16 for
	the purpose of high quality broadband wireless services. A company		the purpose of high-quality broadband wireless services. A company
	can use IEEE 802.16 to build up a mobile office. Wireless Internet		can use IEEE 802.16 to build up a mobile office. Wireless Internet
	spreading through a campus or a cafe can be also implemented with it.		spreading through a campus or a cafe can also be implemented with it.
	+-----+ +-----+ +-----+ ISP 1		+-----+ +-----+ +-----+ ISP 1
	| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network		| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network
	+-----+ | | +-----+ +-----+		+-----+ | | +-----+ +-----+
	+-----+ | +-----+ |		+-----+ | +-----+ |
	| SS2 |<-(16)+-----| BS1 |--|		| SS2 |<-(16)+-----| BS1 |--|
	+-----+ +-----+ | +-----+ +-----+ ISP 2		+-----+ +-----+ | +-----+ +-----+ ISP 2
	+->| AR2 |----| ER2 |===>Network		+->| AR2 |----| ER2 |===>Network
	+-----+ +-----+ +-----+ | +-----+ +-----+		+-----+ +-----+ +-----+ | +-----+ +-----+
	|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+		|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	This network		This network
	behind SS may exist		behind SS may exist
	Figure 4: Fixed/Nomadic Deployment Scenario		Figure 4: Fixed/Nomadic Deployment Scenario
	This scenario also represents IEEE 802.16 network deployment where a		This scenario also represents IEEE 802.16 network deployment where a
	subnet consists of multiple MSs and multiple interfaces of the		subnet consists of multiple MSs and multiple interfaces of the
	multiple BSs. Multiple access routers can exist. There exist		multiple BSs. Multiple access routers can exist. There exist
	multiple hosts behind an SS (networks behind an SS may exist). When		multiple hosts behind an SS (networks behind an SS may exist). When
	802.16 access networks are widely deployed as in a WLAN, this case		802.16 access networks are widely deployed as in a Wireless Local
	should be also considered. The Hot-zone deployment model falls		Area Network (WLAN), this case should also be considered. The Hot-
	within this case.		zone deployment model falls within this case.
	While Figure 4 illustrates a generic deployment scenario, the		While Figure 4 illustrates a generic deployment scenario, the
	following Figure 5 shows in more detail how an existing DSL ISP would		following, Figure 5, shows in more detail how an existing DSL ISP
	integrate the 802.16 access network into its existing infrastructure.		would integrate the 802.16 access network into its existing
			infrastructure.
	+-----+ +---+ +-----+ +-----+ ISP 1		+-----+ +---+ +-----+ +-----+ ISP 1
	| SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network		| SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network
	+-----+ | | b| | +-----+ +-----+		+-----+ | | b| | +-----+ +-----+
	+-----+ | +-----+ |E r| |		+-----+ | +-----+ |E r| |
	| SS2 |<-(16)+-----| BS1 |-----|t i| |		| SS2 |<-(16)+-----| BS1 |-----|t i| |
	+-----+ +-----+ |h d|--+		+-----+ +-----+ |h d|--+
	| g| | +-----+ +-----+ ISP 2		| g| | +-----+ +-----+ ISP 2
	+-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network		+-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network
	| SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+		| SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+
	+-----+ +-----+ +---+ |		+-----+ +-----+ +---+ |
	|		|
	+-----+ +-----+ |		+-----+ +-----+ |
	| TE |<-(DSL)-----|DSLAM|------------+		| TE |<-(DSL)-----|DSLAM|------------+
	+-----+ +-----+		+-----+ +-----+
	Figure 5: Integration of 802.16 access into DSL infrastructure		Figure 5: Integration of 802.16 Access into the 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 the BRAS (Broadband Remote Access Server).		integrated into the BRAS (Broadband Remote Access Server).
	2.2.2.1. IPv6 Related Infrastructure Changes		2.2.2.1. IPv6-Related Infrastructure Changes
	IPv6 will be deployed in this scenario by upgrading the following		IPv6 will be deployed in this scenario by upgrading the following
	devices to dual-stack: MS, AR, ER, and the Ethernet Bridge. The BS		devices to dual stack: MS, AR, ER, and the Ethernet bridge. The BS
	should support IPv6 classifiers as specified in [IEEE802.16].		should support IPv6 classifiers as specified in [IEEE802.16].
	The BRAS in Figure 5 is providing the functionality of the AR. An		The BRAS in Figure 5 is providing the functionality of the AR. An
	Ethernet bridge is necessary for protecting the BRAS from 802.16 link		Ethernet bridge is necessary for protecting the BRAS from 802.16 link
	layer peculiarities. The Ethernet bridge relays all traffic received		layer peculiarities. The Ethernet bridge relays all traffic received
	through the BS to its network side port(s) connected to the BRAS.		through the BS to its network side port(s) connected to the BRAS.
	Any traffic received from the BRAS is relayed to the appropriate BS.		Any traffic received from the BRAS is relayed to the appropriate BS.
	Since the 802.16 MAC layer has no native support for multicast (and		Since the 802.16 MAC layer has no native support for multicast (and
	broadcast) in the uplink direction, the Ethernet bridge will		broadcast) in the uplink direction, the Ethernet bridge will
	implement multicast (and broadcast) by relaying the multicast frame		implement multicast (and broadcast) by relaying the multicast frame
	received from the MS to all of its ports. The Ethernet bridge may		received from the MS to all of its ports. The Ethernet bridge may
	also provide some IPv6 specific functions to increase link efficiency		also provide some IPv6-specific functions to increase link efficiency
	of the 802.16 radio link (see Section 2.2.2.3).		of the 802.16 radio link (see Section 2.2.2.3).
	2.2.2.2. Addressing		2.2.2.2. Addressing
	One or more IPv6 prefixes can be shared to all the attached MSs.		One or more IPv6 prefixes can be shared to all the attached MSs.
	Prefix delegation can be required if networks exist behind the SS.		Prefix delegation can be required if networks exist behind the SS.
	2.2.2.3. IPv6 Transport		2.2.2.3. IPv6 Transport
	Transmisson of IPv6 over Ethernet CS follows [RFC2464] and does not		Transmission of IPv6 over Ethernet CS follows [RFC2464] and does not
	introduce any changes to [RFC4861] and [RFC4862]. However, there are		introduce any changes to [RFC4861] and [RFC4862]. However, there are
	a few considerations in the viewpoint of operation, such as		a few considerations in the viewpoint of operation, such as
	preventing periodic router advertisement messages from an access		preventing periodic router advertisement messages from an access
	router and broadcast transmission, deciding path MTU size, and so on.		router and broadcast transmission, deciding path MTU size, and so on.
	The details about the considerations are described in		The details about the considerations are described in [IP-ETHERNET].
	[I-D.ietf-16ng-ip-over-ethernet-over-802.16].
	2.2.2.4. Routing		2.2.2.4. Routing
	In this scenario, IPv6 multi-homing considerations exist. For		In this scenario, IPv6 multi-homing considerations exist. For
	example, if there exist two routers to support MSs, a default router		example, if there exist two routers to support MSs, a default router
	must be selected.		must be selected.
	The Edge Router runs the IGP used in the SP network such as OSPFv3		The Edge Router runs the IGP used in the SP network such as OSPFv3
	[RFC2740] or IS-IS for IPv6. The connected prefixes have to be		[RFC2740] or IS-IS for IPv6. The connected prefixes have to be
	redistributed. Prefix summarization should be done at the Edge		redistributed. Prefix summarization should be done at the Edge
	Router.		Router.
	2.2.2.5. Mobility		2.2.2.5. Mobility
	No mobility functions of Layer 2 and Layer 3 are supported in the		No mobility functions of Layer 2 and Layer 3 are supported in the
	fixed access scenario. Like WLAN technology, however, nomadicity can		fixed access scenario. Like WLAN technology, however, nomadicity can
	be supported in the radio coverage without any mobility protocol.		be supported in the radio coverage without any mobility protocol.
	So, a user can access Internet nomadically in the coverage.		So, a user can access Internet nomadically in the coverage.
	Sometime, service users can demand IP session continuity or home		Sometimes, service users can demand IP session continuity or home
	address reusability even in the nomadic environment. In case of		address reusability even in the nomadic environment. In that case,
	that, Mobile IPv6 [RFC3775] may be used in this scenario even in the		Mobile IPv6 [RFC3775] may be used in this scenario even in the
	absence of Layer 2's mobility support.		absence of Layer 2's mobility support.
	2.3. IPv6 Multicast		2.3. IPv6 Multicast
	[I-D.ietf-16ng-ip-over-ethernet-over-802.16] realizes IPv6 multicast		[IP-ETHERNET] realizes IPv6 multicast support by Internet Group
	support by IGMP/MLD proxying [RFC4605] and IGMP/MLD snooping		Management Protocol/Multicast Listener Discovery (IGMP/MLD) proxying
	[RFC4541]. Additionally, it may be possible to efficiently implement		[RFC4605] and IGMP/MLD snooping [RFC4541]. Additionally, it may be
	multicast packet transmission among the multicast subscribers by		possible to efficiently implement multicast packet transmission among
	means of IEEE 802.16 Multicast CIDs. However, such a protocol is not		the multicast subscribers by means of IEEE 802.16 Multicast CIDs.
	yet available and under development in WiMAX Forum.		However, such a protocol is not yet available and under development
			in WiMAX Forum.
	2.4. IPv6 QoS		2.4. IPv6 QoS
	In IEEE 802.16 networks, a connection is unidirectional and has a QoS		In IEEE 802.16 networks, a connection is unidirectional and has a
	specification. Each connection is associated with a single data		Quality of Service (QoS) specification. Each connection is
	service flow and each service flow is associated with a set of QoS		associated with a single data service flow, and each service flow is
	parameters in [IEEE802.16]. The QoS related parameters are managed		associated with a set of QoS parameters in [IEEE802.16]. The QoS-
	using the Dynamic Service Addition (DSA) and Dynamic Service Change		related parameters are managed using the Dynamic Service Addition
	(DSC) MAC management messages that specified in [IEEE802.16]. The		(DSA) and Dynamic Service Change (DSC) MAC management messages
	[IEEE802.16] provides QoS differentiation for the different types of		specified in [IEEE802.16]. The [IEEE802.16] provides QoS
	applications by five scheduling service. Four scheduling services		differentiation for the different types of applications by five
	are defined in 802.16 such as Unsolicited Grant Service (UGS), real-		scheduling services. Four scheduling services are defined in 802.16:
	time Polling Service (rtPS), non-real-time Polling Service (nrtPS)		Unsolicited Grant Service (UGS), real-time Polling Service (rtPS),
	and Best Effort (BE). A fifth scheduling service is Extended Real-		non-real-time Polling Service (nrtPS), and Best Effort (BE). A fifth
	time Polling Service (ertPS) that is defined in [IEEE802.16e]. It is		scheduling service is Extended Real-time Polling Service (ertPS),
	required to provide IP layer quality of service mapping to MAC layer		defined in [IEEE802.16e]. It is required to define IP layer quality
	QoS types [IEEE802.16], [IEEE802.16e].		of service mapping to MAC layer QoS types [IEEE802.16],
			[IEEE802.16e].
	2.5. IPv6 Security		2.5. IPv6 Security
	When initiating the connection, an MS is authenticated by the AAA		When initiating the connection, an MS is authenticated by the
	server located at its service provider network. To achieve that, the		Authentication, Authorization, and Accounting (AAA) server located at
	MS and the BS use Privacy Key Management [IEEE802.16],[IEEE802.16e],		its service provider network. To achieve that, the MS and the BS use
	while the BS communicates with the AAA server using a AAA protocol.		Privacy Key Management [IEEE802.16],[IEEE802.16e], while the BS
	Once the MS is authenticated with the AAA server, it can associate		communicates with the AAA server using a AAA protocol. Once the MS
	successfully with the BS and acquire an IPv6 address through		is authenticated with the AAA server, it can associate successfully
	stateless autoconfiguration or DHCPv6. Note that the initiation and		with the BS and acquire an IPv6 address through stateless auto-
	authentication process is the same as the one used in IPv4.		configuration or DHCPv6. Note that the initiation and authentication
			process is the same as the one used in IPv4.
	2.6. IPv6 Network Management		2.6. IPv6 Network Management
	[IEEE802.16f] includes the management information base for IEEE		[IEEE802.16f] includes the management information base for IEEE
	802.16 networks. For IPv6 network management, the necessary		802.16 networks. For IPv6 network management, the necessary
	instrumentation (such as MIBs, NetFlow Records, etc) should be		instrumentation (such as MIBs, NetFlow Records, etc.) should be
	available.		available.
	Upon entering the network, an MS is assigned three management		Upon entering the network, an MS is assigned three management
	connections in each direction. These three connections reflect the		connections in each direction. These three connections reflect the
	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
	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 networks can be managed by IPv4 or IPv6 when		IPv6-based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
	network elements are implemented dual stack. For example, network		network elements are implemented dual stack. SNMP messages can be
	management systems (NMS) can send SNMP messages by IPv4 with IPv6		carried by either IPv4 or IPv6.
	related object identifiers. Also, an NMS can use IPv6 for SNMP
	requests and responses including IPv4 related OID.
	3. IANA Considerations
	This document requests no action by IANA.
	4. Security Considerations		3. Security Considerations
	This document provides a detailed description of various IPv6		This document provides a detailed description of various IPv6
	deployment scenarios and link models for IEEE 802.16 based networks,		deployment scenarios and link models for IEEE 802.16-based networks,
	and as such does not introduce any new security threats. No matter		and as such does not introduce any new security threats. No matter
	what the scenario applied is, the networks should employ the same		what the scenario applied is, the networks should employ the same
	link-layer security mechanisms defined in [IEEE802.16e] and IPv6		link layer security mechanisms defined in [IEEE802.16e] and IPv6
	transition security considerations defined in [RFC4942]. However, as		transition security considerations defined in [RFC4942]. However, as
	already described in [RFC4968], a shared prefix model based mobile		already described in [RFC4968], a shared prefix model-based mobile
	access deployment scenario may security implications for protocols		access deployment scenario may have security implications for
	that are designed to work within the scope. This is the concern for		protocols that are designed to work within the scope. This is the
	a shared prefix link model wherein private resources cannot be put		concern for a shared prefix link model wherein private resources
	onto a public 802.16 based networks. This may restrict the usage of		cannot be put onto a public 802.16-based network. This may restrict
	a shared prefix model to enterprise environments.		the usage of a shared prefix model to enterprise environments.
	5. Acknowledgements		4. Acknowledgements
	This work extends v6ops work on [RFC4779]. We thank all the authors		This work extends v6ops work on [RFC4779]. We thank all the authors
	of the document. Special thanks are due to Maximilian Riegel, Jonne		of the document. Special thanks are due to Maximilian Riegel, Jonne
	Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj		Soininen, Brian E. Carpenter, Jim Bound, David Johnston, Basavaraj
	Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin		Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin
	Jeong, and Jinhyeock Choi for extensive review of this document. We		Jeong, and Jinhyeock Choi for extensive review of this document. We
	acknowledge Dominik Kaspar for proofreading the document.		acknowledge Dominik Kaspar for proofreading the document.
	6. References		5. References
	6.1. Normative References		5.1. Normative References
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		Soliman, "Neighbor Discovery for IP version 6
			(IPv6)", RFC 4861, September 2007.
			[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
			Stateless Address Autoconfiguration", RFC 4862,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		5.2. Informative References
	Address Autoconfiguration", RFC 4862, September 2007.
	6.2. Informative References		[IEEE802.16] "IEEE 802.16-2004, IEEE Standard for Local and
			Metropolitan Area Networks, Part 16: Air
			Interface for Fixed Broadband Wireless Access
			Systems", October 2004.
	[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and		[IEEE802.16e] "IEEE Standard for Local and Metropolitan Area
	J. Palet, "ISP IPv6 Deployment Scenarios in Broadband		Networks Part 16: Air Interface for Fixed and
	Access Networks", RFC 4779, January 2007.		Mobile Broadband Wireless Access Systems
			Amendment 2: Physical and Medium Access Control
			Layers for Combined Fixed and Mobile Operation in
			Licensed Bands and Corrigendum 1", February 2006.
	[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16		[IEEE802.16f] "Amendment to IEEE Standard for Local and
	Based Networks", RFC 4968, August 2007.		Metropolitan Area Networks, Part 16: Air
			Interface for Fixed Broadband Wireless Access
			Systems - Management Information Base",
			December 2005.
	[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/		[IEEE802.16g] "Draft Amendment to IEEE Standard for Local and
	Co-existence Security Considerations", RFC 4942,		Metropolitan Area Networks, Part 16: Air
	September 2007.		Interface for Fixed Broadband Wireless Access
			Systems - Management Plane Procedures and
			Services", January 2007.
	[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",		[IP-ETHERNET] Jeon, H., Riegel, M., and S. Jeong, "Transmission
	RFC 2740, December 1999.		of IP over Ethernet over IEEE 802.16 Networks",
			Work in Progress, April 2008.
			[MIPSHOP-FH80216E] Jang, H., Jee, J., Han, Y., Park, S., and J. Cha,
			"Mobile IPv6 Fast Handovers over IEEE 802.16e
			Networks", Work in Progress, March 2008.
			[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
			Ethernet Networks", RFC 2464, December 1998.
			[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
			IPv6", RFC 2740, December 1999.
	[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third		[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
	Generation Partnership Project (3GPP) Standards",		Generation Partnership Project (3GPP) Standards",
	RFC 3314, September 2002.		RFC 3314, September 2002.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
	in IPv6", RFC 3775, June 2004.		Support in IPv6", RFC 3775, June 2004.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, December 1998.
	[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,		[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6",
	"Internet Group Management Protocol (IGMP) / Multicast		RFC 4068, July 2005.
	Listener Discovery (MLD)-Based Multicast Forwarding
	("IGMP/MLD Proxying")", RFC 4605, August 2006.
	[RFC4541] Christensen, M., Kimball, K., and F. Solensky,		[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
	"Considerations for Internet Group Management Protocol		"Considerations for Internet Group Management
	(IGMP) and Multicast Listener Discovery (MLD) Snooping		Protocol (IGMP) and Multicast Listener Discovery
	Switches", RFC 4541, May 2006.		(MLD) Snooping Switches", RFC 4541, May 2006.
	[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
	July 2005.
	[I-D.ietf-16ng-ps-goals]
	Jee, J., Madanapalli, S., and J. Mandin, "IP over 802.16
	Problem Statement and Goals", draft-ietf-16ng-ps-goals-04
	(work in progress), December 2007.
	[I-D.ietf-16ng-ipv6-over-ipv6cs]		[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
	Patil, B., Xia, F., Sarikaya, B., Choi, J., and S.		"Internet Group Management Protocol (IGMP) /
	Madanapalli, "Transmission of IPv6 via the IPv6 CS over		Multicast Listener Discovery (MLD)-Based
	IEEE 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-11		Multicast Forwarding ("IGMP/MLD Proxying")",
	(work in progress), November 2007.		RFC 4605, August 2006.
	[I-D.ietf-16ng-ip-over-ethernet-over-802.16]		[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola,
	Jeon, H., "Transmission of IP over Ethernet over IEEE		P., and J. Palet, "ISP IPv6 Deployment Scenarios
	802.16 Networks",		in Broadband Access Networks", RFC 4779,
	draft-ietf-16ng-ip-over-ethernet-over-802.16-04 (work in		January 2007.
	progress), January 2008.
	[I-D.ietf-mipshop-fh80216e]		[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
	Jang, H., Jee, J., Han, Y., Park, S., and J. Cha, "Mobile		Encapsulation Methods Considered Harmful",
	IPv6 Fast Handovers over IEEE 802.16e Networks",		RFC 4840, April 2007.
	draft-ietf-mipshop-fh80216e-05 (work in progress),
	November 2007.
	[IEEE802.16]		[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
	"IEEE 802.16-2004, IEEE Standard for Local and		Transition/Co-existence Security Considerations",
	Metropolitan Area Networks, Part 16: Air Interface for		RFC 4942, September 2007.
	Fixed Broadband Wireless Access Systems", October 2004.
	[IEEE802.16e]		[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models
	"IEEE Standard for Local and Metropolitan Area Networks		for 802.16 Based Networks", RFC 4968,
	Part 16: Air Interface for Fixed and Mobile Broadband		August 2007.
	Wireless Access Systems Amendment 2: Physical and Medium
	Access Control Layers for Combined Fixed and Mobile
	Operation in Licensed Bands and Corrigendum 1",
	February 2006.
	[IEEE802.16g]		[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and
	"Draft Amendment to IEEE Standard for Local and		S. Madanapalli, "Transmission of IPv6 via the
	Metropolitan Area Networks, Part 16: Air Interface for		IPv6 Convergence Sublayer over IEEE 802.16
	Fixed Broadband Wireless Access Systems - Management Plane		Networks", RFC 5121, February 2008.
	Procedures and Services", January 2007.
	[IEEE802.16f]		[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over
	"Amendment to IEEE Standard for Local and Metropolitan		IEEE 802.16 Problem Statement and Goals",
	Area Networks, Part 16: Air Interface for Fixed Broadband		RFC 5154, April 2008.
	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
	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
	Sang-Eon Kim		Sang-Eon Kim
	KT		KT
	17 Woomyeon-dong, Seocho-gu		17 Woomyeon-dong, Seocho-gu
	Seoul, 137-791		Seoul, 137-791
	Korea		Korea
	Email: sekim@kt.co.kr		EMail: sekim@kt.com
	Domagoj Premec		Domagoj Premec
	Siemens Mobile		Siemens Mobile
	Heinzelova 70a		Heinzelova 70a
	10010 Zagreb		10010 Zagreb
	Croatia		Croatia
	Email: domagoj.premec@siemens.com		EMail: domagoj.premec@siemens.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 17, line 44		skipping to change at line 716
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	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.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 86 change blocks.
	275 lines changed or deleted		258 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/