draft-ietf-dime-pmip6-00.txt		draft-ietf-dime-pmip6-01.txt
	Diameter Maintenance and J. Korhonen, Ed.		Diameter Maintenance and J. Korhonen, Ed.
	Extensions (DIME) Nokia Siemens Network		Extensions (DIME) Nokia Siemens Network
	Internet-Draft J. Bournelle		Internet-Draft J. Bournelle
	Intended status: Standards Track Orange Labs		Intended status: Standards Track Orange Labs
	Expires: July 18, 2009 A. Muhanna		Expires: September 7, 2009 K. Chowdhury
	Nortel
	K. Chowdhury
	Starent Networks		Starent Networks
			A. Muhanna
			Nortel
	U. Meyer		U. Meyer
	RWTH Aachen		RWTH Aachen
	January 14, 2009		March 6, 2009
	Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local		Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility
	Mobility Anchor to Diameter Server Interaction		Anchor Interaction with Diameter Server
	draft-ietf-dime-pmip6-00.txt		draft-ietf-dime-pmip6-01.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 18, 2009.		This Internet-Draft will expire on September 7, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	This specification defines the Diameter support for the Proxy Mobile		This specification defines the Diameter support for the Proxy Mobile
	IPv6 and the corresponding mobility service session setup. The		IPv6 and the corresponding mobility service session setup. The
	policy information needed by the Proxy Mobile IPv6 is defined in		policy information needed by the Proxy Mobile IPv6 is defined in
	mobile node's policy profile, which could be downloaded from the		mobile node's policy profile, which could be downloaded from the
	Diameter server to the Mobile Access Gateway once the mobile node		Diameter server to the Mobile Access Gateway once the mobile node
	roams into a Proxy Mobile IPv6 Domain and performs access		attaches to a Proxy Mobile IPv6 Domain and performs access
	authentication.		authentication. During the binding update exchange between the
			Mobile Access Gateway and the Local Mobility Anchor, the Local
			Mobility Anchor can interact with the Diameter server in order to
			update the remote policy store with the mobility session related
			information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
	3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5		3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
	4. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 7		4. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 7
	4.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 7		4.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 7
	4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 7		4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 7
	4.3. PMIP6-DHCP-Address AVP . . . . . . . . . . . . . . . . . . 8		4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 8
	4.4. PMIP6-Home-Prefix AVP . . . . . . . . . . . . . . . . . . 8		4.4. PMIP6-DHCP-Server-Address AVP . . . . . . . . . . . . . . 8
	4.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 8		4.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 8
	4.6. Mobile-Node-Identifier AVP . . . . . . . . . . . . . . . . 9		4.6. Mobile-Node-Identifier AVP . . . . . . . . . . . . . . . . 9
	4.7. Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . 10		4.7. Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . 9
	4.8. Service-Selection AVP . . . . . . . . . . . . . . . . . . 10		4.8. Service-Selection AVP . . . . . . . . . . . . . . . . . . 10
	4.9. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 10		4.9. Service-Configuration AVP . . . . . . . . . . . . . . . . 10
	5. MAG to HAAA Interface Application Support . . . . . . . . . . 10		5. Application Support and Command Codes . . . . . . . . . . . . 11
	5.1. Application Support and Command Codes . . . . . . . . . . 10		5.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 11
	5.2. Accounting at MAG . . . . . . . . . . . . . . . . . . . . 11		5.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 11
	6. LMA to HAAA Interface Application Support . . . . . . . . . . 11		5.2.1. Authorization of the Proxy Binding Update . . . . . . 12
	6.1. Application Support and Command Codes . . . . . . . . . . 11		6. Proxy Mobile IPv6 Session Management . . . . . . . . . . . . . 12
	6.2. Authorization of the Proxy Binding Update . . . . . . . . 11		6.1. Session-Termination-Request . . . . . . . . . . . . . . . 13
	6.2.1. LHA-Request . . . . . . . . . . . . . . . . . . . . . 12		6.2. Session-Termination-Answer . . . . . . . . . . . . . . . . 13
	6.2.2. LHA-Answer . . . . . . . . . . . . . . . . . . . . . . 13		6.3. Abort-Session-Request . . . . . . . . . . . . . . . . . . 13
	6.3. Accounting at LMA . . . . . . . . . . . . . . . . . . . . 14		6.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . . . 13
	7. Proxy Mobile IPv6 Session Management . . . . . . . . . . . . . 14		7. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 13
	7.1. Session-Termination-Request . . . . . . . . . . . . . . . 15		7.1. MAG-to-HAAA Interface . . . . . . . . . . . . . . . . . . 14
	7.2. Session-Termination-Answer . . . . . . . . . . . . . . . . 15		7.2. LMA-to-HAAA Interface . . . . . . . . . . . . . . . . . . 14
	7.3. Abort-Session-Request . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . . . 15		8.1. Attribute Value Pair Codes . . . . . . . . . . . . . . . . 14
	8. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 15		8.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. MAG to HAAA Interface . . . . . . . . . . . . . . . . . . 15		8.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 15
	8.2. LMA to HAAA Interface . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Attribute Value Pair Codes . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.3. Application Identifiers . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 16
	9.4. Command Codes . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.5. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 18
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	12.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	In the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and its IPv4		In the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and IPv4 support
	support [I-D.ietf-netlmm-pmip6-ipv4-support] a Mobile Access Gateway		for Proxy Mobile IPv6 [I-D.ietf-netlmm-pmip6-ipv4-support] a Mobile
	(MAG) performs a proxy registration with a Local Mobility Anchor		Access Gateway (MAG) performs a proxy registration with a Local
	(LMA) on behalf of the mobile node (MN). In order to perform the		Mobility Anchor (LMA) on behalf of the mobile node (MN). In order to
	proxy registration the PMIPv6 MAG needs the address of the LMA,		perform the proxy registration the MAG needs the IP address of the
	possibly MN's home network prefix (MN-HNP), possibly MN's IPv4 home		LMA, possibly MN's Home Network Prefix(es) (MN-HNP), MN's IPv4 home
	address (IPv4-HoA), DHCP server address and other PMIPv6 specific		address (IPv4-MN-HoA), DHCP server address and other PMIPv6 specific
	information such as allowed address configuration modes and possible		information such as the allowed address configuration modes and
	roaming related policies. All this information is defined in MN's		roaming related policies. All this information is defined in MN's
	policy profile that gets downloaded from the Diameter server to the		policy profile that gets downloaded from the Diameter server to the
	MAG once the MN roams into a Proxy Mobile IPv6 Domain (PMIPv6-Domain)		MAG once the MN attaches to the MAG's Proxy Mobile IPv6 Domain
	and performs the access authentication.		(PMIPv6 Domain) and performs the access authentication.
	Dynamic assignment and downloading of PMIPv6 policy profile		Dynamic assignment and downloading of PMIPv6 policy profile
	information is a desirable feature to ease the deployment and network		information is a desirable feature to ease the deployment and network
	maintenance of larger PMIPv6 deployments. For this purpose, the AAA		maintenance of larger PMIPv6 deployments. For this purpose, the
	infrastructure, which is used for access authentication, can be		Authentication, Authorization, and Accounting (AAA) infrastructure,
	leveraged to assign some or all of the necessary parameters. The		which is used for access authentication, can be leveraged to assign
	Diameter server in the Mobility Service authorizer's (MSA) or in the		some or all of the necessary parameters. The Diameter server in the
	Mobility Service Provider's (MSP) network may return these parameters		Mobility Service authorizer's (MSA) network may return these
	to the Network Access Server (NAS).		parameters to the Network Access Server (NAS).
	Once the MN authenticates to the network the MAG sends a Proxy		Once the MN authenticates to the network the MAG sends a Proxy
	Binding Update (PBU) towards the LMA on behalf of the MN. Upon		Binding Update (PBU) towards the LMA on behalf of the MN. When the
	arrival of the PBU the LMA needs to interact with the Diameter server		LMA receives the PBU, the LMA may need to update the remote policy
	and fetch the MN's policy related information that was already		store located in the MSA with the MN's mobility session related
	partially downloaded to the MAG.		information.
	This specification defines the Diameter support for the PMIPv6 and		This specification defines the Diameter support for PMIPv6. In the
	the corresponding mobility service session setup. In the context of		context of this specification the location of the subscriber policy
	this specification the location of the subscriber policy profile		profile equals to the home Diameter server, which is also referred as
	equals to the home Diameter server, which is also referred as the		the home AAA server (HAAA). The NAS functionality of the MAG may be
	home AAA server (HAAA). The NAS functionality of the MAG may be co-		co-located or an integral part of the MAG.
	located or an integral part of the MAG. The access authentication
	procedure into a PMIPv6-Domain resembles the Mobile IPv6 integrated
	scenario bootstrapping [I-D.ietf-dime-mip6-integrated]. The
	assumption is that the Access Service Authenticator (ASA) is the same
	entity as the MSA/MSP. This specification leverages the work already
	done for the Mobile IPv6 integrated scenario bootstrapping
	[I-D.ietf-dime-mip6-integrated].
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	General mobility terminology can be found in [RFC3753]. The		The general terminology used in this document can be found in
	following additional or clarified terms are used in this document:		[RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support]. The following
			additional or clarified terms are also used in this document:
	Network Access Server (NAS):		Network Access Server (NAS):
	A device that provides an access service for a user to a network.		A device that provides an access service for a user to a network.
	In the context of this document the NAS may be integrated into or		In the context of this document the NAS may be integrated into or
	co-located to a MAG. The NAS contains a Diameter client function.		co-located to a MAG. The NAS contains a Diameter client function.
	Home AAA (HAAA):		Home AAA (HAAA):
	An authentication, authorization and accounting server located in		An Authentication, Authorization, and Accounting (AAA) server
	user's home network. A HAAA is essentially a Diameter server.		located in user's home network. A HAAA is essentially a Diameter
			server.
	3. Solution Overview		3. Solution Overview
	This document addresses the authentication, authorization, accounting		This document addresses the AAA interactions and AAA-based session
	and session management functionality needed by the PMIPv6 protocol.		management functionality needed in the PMIPv6 Domain. This document
	This document defines Diameter based interfaces between the PMIPv6		defines Diameter based AAA interactions between the MAG and the HAAA,
	two entities, MAG and HAAA, to the HAAA. The intention of this		and between the LMA and the HAAA.
	document is only to extend existing Diameter Mobile IPv6
	specifications such as [I-D.ietf-dime-mip6-integrated] and define the
	needed additional AVPs and functionality to fully support PMIPv6
	deployment.
	The policy profile download from the HAAA to the MAG is part of the		The policy profile is downloaded from the HAAA to the MAG during the
	network access authentication procedure when a MN roams into or		MN attachment to the PMIPv6 Domain. Figure 1 shows the participating
	within a PMIPv6 Domain. Figure 1 shows the participating network		network entities. This document, however, concentrates on the MAG,
	entities. This document, however, only concentrates on the MAG, LMA,		LMA, and the home Diameter server.
	possible local Diameter proxies and the home Diameter server. When
	aligned with [I-D.ietf-dime-mip6-integrated] the MAG acts as the NAS
	located in ASP, the HAAA acts as the Diameter server located in ASA/
	MSA/MSP and the LMA acts as the HA in ASP/MSP.
	+--------+		+--------+
	| HAAA & | Diameter +-----+		| HAAA & | Diameter +-----+
	| Policy |<---(1)-->| LMA |		| Policy |<---(2)-->| LMA |
	| Profile| +-----+		| Profile| +-----+
	+--------+ | <--- LMA-Address		+--------+ | <--- LMA-Address
	^ |		^ |
	| // \\		| // \\
	+---|------------- //---\\----------------+		+---|------------- //---\\----------------+
	( | IPv4/IPv6 // \\ )		( | IPv4/IPv6 // \\ )
	( | Network // \\ )		( | Network // \\ )
	+---|-----------//---------\\-------------+		+---|-----------//---------\\-------------+
	| // \\		| // \\
	Diameter // <- Tunnel1 \\ <- Tunnel2		Diameter // <- Tunnel1 \\ <- Tunnel2
	(2) // \\		(1) // \\
	| |- MAG-Address1 |- MAG-Address2		| |- MAG1-Address |- MAG2-Address
	| +----+ +----+		| +----+ +----+
	+---->|MAG1| |MAG2|		+---->|MAG1| |MAG2|
	+----+ +----+		+----+ +----+
	| |		| |
	| |		| |
	[MN1] [MN2]		[MN1] [MN2]
	Legend:		Legend:
	(1): LMA <-> HAAA interaction is described		(1): MAG-to-HAAA interaction is described
	in Section 6		in Section 5.1
	(2): MAG <-> HAAA interaction is described		(2): LMA-to-HAAA interaction is described
	in Section 5		in Section 5.2
	Figure 1: Diameter Proxy Mobile IPv6 Support with MAG to HAAA and LMA		Figure 1: Proxy Mobile IPv6 Domain Interaction with Diameter HAAA
	to HAAA Interfaces		Server
	In a PMIPv6 access scenario a MN attaches to a PMIPv6-Domain and		When a MN attaches to a PMIPv6 Domain, a network access
	starts a network access authentication procedure. The choice of the		authentication procedure is usually started. The choice of the
	authentication mechanism is specific to the access network		authentication mechanism is specific to the access network
	deployment, but could be based on the Extensible Authentication		deployment, but could be based on the Extensible Authentication
	Protocol (EAP) [RFC3748]. During the network access authentication		Protocol (EAP) [RFC3748]. During the network access authentication
	procedure, the MAG acting as a NAS queries the HAAA through the AAA		procedure, the MAG acting as a NAS queries the HAAA through the AAA
	infrastructure using the Diameter protocol. If the HAAA detects that		infrastructure using the Diameter protocol. If the HAAA detects that
	the subscriber is also authorized for the PMIPv6 service, the		the subscriber is also authorized for the PMIPv6 service, PMIPv6
	subscriber policy is returned along with the successful network		specific information is returned along with the successful network
	access authentication answer to the MAG.		access authentication answer to the MAG.
	After the MN access is successfully authenticated, the MAG sends a		After the MN has been successfully authenticated, the MAG sends a PBU
	PBU to the LMA. Upon receiving the PBU the LMA interacts with the		to the LMA based on the MN's policy profile information. Upon
	HAAA and fetches the relevant subscriber policy, authorization and		receiving the PBU the LMA interacts with the HAAA and fetches the
	security information related to the PMIPv6 session. This		relevant parts of the subscriber policy profile and authorization
	specification assumes that the HAAA is the central node for managing		information related to the mobility service session. In this
	everything related to PMIPv6 subscription and session, possibly even		specification, the HAAA has the role of the PMIPv6 remote policy
	including the allocation of prefixes.		store.
	Prior to sending the PBU there might be a need to dynamically setup
	the MAG to LMA Security Association (SA), for example using IKEv2/
	IPSec [RFC4306]. The dynamic SA setup procedure may be triggered by
	the MN attaching to the MAG that does not have an existing SA with
	the correspondent LMA. The details of the dynamic SA setup procedure
	is out of scope of this specification. However, the SA is between
	the MAG and the corresponding LMA, thus it can be created using any
	security mechanism that is applicable for PMIPv6 security such as
	IKEv2 IPSec with an EAP-based authentication. It should be noted
	that the identity used by the MAG during the SA creation is the MAG's
	own identity and the credentials are for authenticating the MAG
	toward the LMA and possibly for authorizing the MAG to offer Proxy
	Mobile IPv6 service with the same LMA.
	4. Attribute Value Pair Definitions		4. Attribute Value Pair Definitions
	This section describes both new AVPs defined in this specification		This section describes Attribute Value Pairs (AVPs) defined by this
	and re-used AVPs that are used in a PMIPv6 specific way. The AVPs		specification or re-used from existing specifications in a PMIPv6
	described here are applicable for both MAG to HAAA and LMA to HAAA		specific way.
	interfaces.
	4.1. MIP6-Agent-Info AVP		4.1. MIP6-Agent-Info AVP
	The MIP6-Agent-Info grouped AVP is defined in		The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
	[I-D.ietf-dime-mip6-integrated]. This specification reuses the said		[RFC5447]. The AVP is used to carry LMA addressing related
	AVP and its sub-AVPs to carry the LMA IP address and/or FQDN.		information and a MN-HNP. This specification extends the MIP6-Agent-
			Info with the PMIP6-IPv4-Home-Address AVP using the Diameter
			extensibility rules defined in [RFC3588]. The PMIP6-IPv4-Home-
			Address AVP contains the IPv4-MN-HoA.
			The extended MIP6-Agent-Info AVP results to the following grouped
			AVP:
			MIP6-Agent-Info ::= < AVP-Header: 486 >
			*2[ MIP-Home-Agent-Address ]
			[ MIP-Home-Agent-Host ]
			[ MIP6-Home-Link-Prefix ]
			[ PMIP6-IPv4-Home-Address ]
			* [ AVP ]
	4.2. PMIP6-IPv4-Home-Address AVP		4.2. PMIP6-IPv4-Home-Address AVP
	The PMIP6-IPv4-Home-Address AVP (AVP Code TBD) is of type Address and		The PMIP6-IPv4-Home-Address AVP (AVP Code TBD2) is of type Address
	contains the IPv4-HoA of the MN. The primary use of this AVP is to		and contains an IPv4 address. This AVP is used to carry the IPv4-MN-
	carry the IPv4 Home Address, if available, from the HAAA to the MAG.		HoA, if available, from the HAAA to the MAG. This AVP SHOULD only be
			present when the MN is statically provisioned with the IPv4-MN-HoA.
			Note that proactive dynamic assignment of the IPv4-MN-HoA by the HAAA
			may result in unnecessary reservation of IPv4 address resources,
			because the MN may considerably delay or completely bypass its IPv4
			address configuration.
	The PMIP6-IPv4-Home-Address AVP may also be used on the LMA to HAAA		The PMIP6-IPv4-Home-Address AVP is also used on the LMA-to-HAAA
	interface. In this scenario the AVP contains the IPv4 Home Address		interface. The AVP contains the IPv4-MN-HoA assigned to the MN. If
	the LMA has assigned to the MN. If the LMA delegates assignment of		the LMA delegates the assignment of the IPv4-MN-HoA to the HAAA, the
	the Home Address to the HAAA, the AVP MUST contain all zeroes address		AVP MUST contain all zeroes IPv4 address (i.e., 0.0.0.0) in the
	(i.e., 0.0.0.0) in the request message. The answer message SHOULD in		request message. If the LMA delegated the IPv4-MN-HoA assignment to
	all cases contain the assigned IPv4 Home Address value.		the HAAA, then the AVP contains the HAAA assigned IPv4-MN-HoA in the
			response message.
	4.3. PMIP6-DHCP-Address AVP		4.3. MIP6-Home-Link-Prefix AVP
	The PMIP6-DHCP-Address AVP (AVP Code TBD) is of type Address and		The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5447].
	contains the IP address of the DHCPv4 and/or DHCPv6 server assigned		This AVP is used to carry the MN-HNP, if available, from the HAAA to
	to the MAG serving the newly attached MN. If the AVP contains a		the MAG. The low 64 bits of the prefix MUST be all zeroes.
	DHCPv4 server address, then the Address type MUST be IPv4. If the
	AVP contains a DHCPv6 server address, then the Address type MUST be
	IPv6. The HAAA MAY assign a DHCP server to the MAG in deployments
	where the MAG acts as a DHCP Relay and the DHCP Server is not co-
	located with the LMA [I-D.ietf-netlmm-pmip6-ipv4-support].
	4.4. PMIP6-Home-Prefix AVP		The MIP6-Home-Link-Prefix AVP is also used on the LMA-to-HAAA
			interface. The AVP contains the prefix assigned to the MN. If the
			LMA delegates the assignment of the MN-HNP to the HAAA, the AVP MUST
			contain all zeroes address (i.e., 0::0) in the request message. If
			the LMA delegated the MN-HNP assignment to the HAAA, then the AVP
			contains the HAAA assigned MNM-HNP in the response message.
	The PMIP6-Home-Prefix AVP (AVP Code TBD) is of type Address and		4.4. PMIP6-DHCP-Server-Address AVP
	contains the MN-NHP. The low 64 bits of the IPv6 address MUST be all
	zeroes. The high 64 bits of the IPv6 address are used as the MN-HNP.
	The primary use of this AVP is to carry the IPv6 Home Network Prefix,
	if available, from the HAAA to the MAG.
	The PMIP6-Home-Prefix AVP may also be used on the LMA to HAAA		The PMIP6-DHCP-Server-Address AVP (AVP Code TBD1) is of type Address
	interface. In this scenario the AVP contains the prefix the LMA has		and contains the IP address of the DHCPv4 and/or DHCPv6 server
	assigned to the MN. If the LMA delegates assignment of the home		assigned to the MAG serving the newly attached MN. If the AVP
	network prefix to the HAAA, the AVP MUST contain all zeroes address		contains a DHCPv4 server address, then the Address type MUST be IPv4.
	(i.e., 0::0) in the request message. The answer message SHOULD in		If the AVP contains a DHCPv6 server address, then the Address type
	all cases contain the assigned home prefix value.		MUST be IPv6. The HAAA MAY assign a DHCP server to the MAG in
			deployments where the MAG acts as a DHCP Relay
			[I-D.ietf-netlmm-pmip6-ipv4-support].
	4.5. MIP6-Feature-Vector AVP		4.5. MIP6-Feature-Vector AVP
	The MIP6-Feature-Vector AVP is originally defined in		The MIP6-Feature-Vector AVP is originally defined in [RFC5447]. This
	[I-D.ietf-dime-mip6-integrated]. This document only reserves new		document defines new capability flag bits according to the rules in
	capability bits according to the rules in		[RFC5447].
	[I-D.ietf-dime-mip6-integrated]. The new reserved bits contain
	PMIPv6 capability announcement of the MAG and the HAAA(/LMA)). Using
	the capability announcement it is possible to perform a simple
	capability negotiation between the MAG and the HAAA. Those
	capabilities that are announced by both parties are also known to be
	mutually supported. The following capability bits are defined in
	this document:
	PMIP6_SUPPORTED (0x0000010000000000)		PMIP6_SUPPORTED (0x0000010000000000)
	When the MAG/NAS sets this bit in the MIP6-Feature-Vector AVP, it		When the MAG/NAS sets this bit in the MIP6-Feature-Vector AVP, it
	is an indication to the HAAA that the NAS supports PMIPv6. When		is an indication to the HAAA that the NAS supports PMIPv6. When
	the HAAA sets this bit in the response MIP6-Feature-Vector AVP, it		the HAAA sets this bit in the response MIP6-Feature-Vector AVP, it
	indicates that the HAAA also has PMIPv6 support. This capability		indicates that the HAAA also has PMIPv6 support. This capability
	bit can also be used to allow PMIPv6 mobility support in a		bit can also be used to allow PMIPv6 mobility support in a
	subscription granularity.		subscription granularity.
	IP4_HOA_SUPPORTED (0x0000020000000000)		IP4_HOA_SUPPORTED (0x0000020000000000)
	Assignment of the IPv4-HoA is supported. When the MAG sets this		Assignment of the IPv4-MN-HoA is supported. When the MAG sets
	bit in the MIP6-Feature-Vector AVP, it indicates that the MAG		this bit in the MIP6-Feature-Vector AVP, it indicates that the MAG
	implements a minimal functionality of a DHCP server (and a relay)		implements a minimal functionality of a DHCP server (and a relay)
	and is able to deliver IPv4-HoA to the MN. When the HAAA sets		and is able to deliver IPv4-MN-HoA to the MN. When the HAAA sets
	this bit in the response MIP6-Feature-Vector AVP, it indicates		this bit in the response MIP6-Feature-Vector AVP, it indicates
	that the HAAA has authorized the use of IPv4-HoA for the MN. If		that the HAAA has authorized the use of IPv4-MN-HoA for the MN.
	this bit is unset in the returned MIP6-Feature-Vector AVP, the		If this bit is unset in the returned MIP6-Feature-Vector AVP, the
	HAAA does not authorize the configuration of IPv4 address.		HAAA does not authorize the configuration of IPv4 address.
	LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)		LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)
	Direct routing of IP packets between MNs anchored to the same MAG		Direct routing of IP packets between MNs anchored to the same MAG
	is supported. When a MAG sets this bit in the MIP6-Feature-		is supported. When a MAG sets this bit in the MIP6-Feature-
	Vector, it indicates that routing IP packets between MNs anchored		Vector, it indicates that routing IP packets between MNs anchored
	to the same MAG is supported, without reverse tunneling packets		to the same MAG is supported, without reverse tunneling packets
	via the LMA or requiring any Route Optimization related signaling		via the LMA or requiring any Route Optimization related signaling
	(e.g. the Return Routability Procedure in [RFC3775]) prior direct		(e.g. the Return Routability Procedure in [RFC3775]) prior direct
	routing. If this bit is unset in the returned MIP6-Feature-Vector		routing. If this bit is unset in the returned MIP6-Feature-Vector
	AVP, the HAAA does not authorize direct routing of packets between		AVP, the HAAA does not authorize direct routing of packets between
	MNs anchored to the same MAG. This policy feature MUST be		MNs anchored to the same MAG. This policy feature SHOULD be
	supported per MN and subscription basis.		supported per MN and subscription basis.
	The MIP6-Feature-Vector AVP is also used on the LMA to HAAA		The MIP6-Feature-Vector AVP is also used on the LMA to HAAA
	interface. Using the capability announcement AVP it is possible to		interface. Using the capability announcement AVP it is possible to
	perform a simple capability negotiation between the LMA and the HAAA.		perform a simple capability negotiation between the LMA and the HAAA.
	Those capabilities that are announced by both parties are also known		Those capabilities that are announced by both parties are also known
	to be mutually supported. The capabilities listed in earlier are		to be mutually supported. The capabilities listed in earlier are
	also supported in the LMA to HAAA interface. The LMA to HAAA		also supported in the LMA to HAAA interface. The LMA to HAAA
	interface does not define any new capability values.		interface does not define any new capability values.
	4.6. Mobile-Node-Identifier AVP		4.6. Mobile-Node-Identifier AVP
	The Mobile-Node-Identifier AVP (AVP Code TBD) is of type UTF8String		The Mobile-Node-Identifier AVP (AVP Code TBD3) is of type UTF8String
	and contains the mobile node identifier (MN-Identifier, see		and contains the mobile node identifier (MN-Identifier, see
	[RFC5213]) in a NAI [RFC4282] format. This AVP is used on the MAG to		[RFC5213]) in the NAI [RFC4282] format. This AVP is used on the MAG-
	HAAA interface.		to-HAAA interface. The Mobile-Node-Identifier AV is designed for
			deployments where the MAG does not have a way to find out such MN
			identity that could be used in subsequent PBU/PBA exchanges (e.g.,
			due to identity hiding during the network access authentication) or
			the HAAA wants to assign periodically changing identities to the MN.
	The Mobile-Node-Identifier AVP is returned in the answer message that		The Mobile-Node-Identifier AVP is returned in the answer message that
	ends a successful authentication (and possibly an authorization)		ends a successful authentication (and possibly an authorization)
	exchange between the MAG and the HAAA, assuming the HAAA is also able		exchange between the MAG and the HAAA, assuming the HAAA is also able
	to provide the MAG with the MN-Identifier in the first place. The		to provide the MAG with the MN-Identifier in the first place. The
	MAG MUST use the received MN-Identifier, if it has not been able to		MAG MUST use the received MN-Identifier, if it has not been able to
	get the mobile node identifier through other means. If the MAG		get the mobile node identifier through other means. If the MAG
	already has a valid mobile node identifier, then the MAG MAY silently		already has a valid mobile node identifier, then the MAG MUST
	discard the received MN-identifier.		silently discard the received MN-identifier.
	4.7. Calling-Station-Id AVP		4.7. Calling-Station-Id AVP
	The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and		The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
	contains a Link-Layer Identifier of the MN. This identifier may		contains a Link-Layer Identifier of the MN. This identifier
	correspond to a real physical interface or something that the MAG has		corresponds to the Link-Layer Identifier as defined in RFC 5213
	generated.		Section 2.2. and 8.6.
	4.8. Service-Selection AVP		4.8. Service-Selection AVP
	The Service-Selection AVP (AVP Code TBD) is of type UTF8String and		The Service-Selection AVP (AVP Code TBD) is of type UTF8String and
	contains a LMA provided service identifier on the LMA to HAAA		contains a LMA provided service identifier on the LMA-to-HAAA
	interface. The service identifier may be used to assist the PBU		interface. This AVP is re-used from [I-D.ietf-dime-mip6-split]. The
	authorization. The identifier MUST be unique within the PMIPv6		service identifier may be used to assist the PBU authorization and
	domain. This AVP is re-used from [I-D.ietf-dime-mip6-split].		the assignment of the MN-HNP and the IPv4-MN-HoA as described in RFC
			5149 [RFC5149]. The identifier MUST be unique within the PMIPv6
			Domain. In the absence of the Service-Selection AVP in the request
			message, the HAAA may want to inform the LMA of the default service
			provisioned to the MN and include the Service-Selection AVP in the
			response message.
	4.9. Session-Timeout AVP		It is also possible that the MAG receives the service selection
			information from the MN, for example, via some lower layer mechanism.
			In this case the MAG SHOULD include the Service-Selection AVP also in
			the MAG-to-HAAA request messages. In absence of the Service-
			Selection AVP in the MAG-to-HAAA request messages, the HAAA may want
			to inform the MAG of the default service provisioned to the MN and
			include the Service-Selection AVP in the response message.
	The Session-Timeout AVP (AVP Code 27) is of type Unsigned32 and		Whenever the Service-Selection AVP is included either in a request
	contains lifetime of the Binding Cache Entry in a unit of seconds.		message or in a response message, and the AAA interaction with HAAA
			completes successfully, it is an indication that the HAAA also
			authorized the MN to some service. This should be taken into account
			when considering what to include in the Auth-Request-Type AVP.
	5. MAG to HAAA Interface Application Support		The service selection concept supports signaling one service at time.
			However, the MN policy profile MAY support multiple services being
			used simultaneously. For this purpose, the HAAA MAY return multiple
			LMA and service pairs (see Section 4.9) to the MAG in a response
			message that ends a successful authentication (and possibly an
			authorization) exchange between the MAG and the HAAA. Whenever the
			MN initiates additional mobility session to another service (using a
			link layer or deployment specific method), the provisioned service
			information is already contained in the MAG. Therefore, there is no
			need for additional AAA signaling between the MAG and the HAAA.
	5.1. Application Support and Command Codes		4.9. Service-Configuration AVP
	This specification does not define a new Application-ID for the MAG		The Service-Configuration AVP (AVP Code TBD4) is of type Grouped and
	to HAAA interface. Rather, this specification re-uses any Diameter		contains a service and a LMA pair. The HAAA can use this AVP to
	application and its commands that are used to authenticate and		inform the MAG of MN's subscribed services and LMAs where those
	authorize the MN for the network access and mobility service.		services are hosted in.
	Example applications include NASREQ [RFC4005] and EAP [RFC4072]. The
	MAG acts as a Diameter client.
	The MAG to HAAA interface is primarily used for bootstrapping PMIPv6		Service-Configuration ::= < AVP-Header: TBD4 >
	mobility service session when a MN attaches and authenticates to a		[ MIP6-Agent-Info ]
	PMIPv6 domain. This includes the bootstrapping of PMIPv6 session		[ Service-Selection ]
	related information and possibly PMIPv6 security related information		* [ AVP ]
	retrieval. The same interface may also be used for accounting.
	Whenever the MAG sends a Diameter request message to the HAAA the		5. Application Support and Command Codes
	User-Name AVP MUST contain the MN identity. At minimum the home
	realm of the MN MUST be available at the MAG when the network access
	authentication takes place. Otherwise the MAG is not able to route
	the Diameter request messages towards the correct HAAA. The MN
	identity MUST be in Network Access Identifier (NAI) [RFC4282] format.
	The Diameter response messages MAY contain Framed-IPv6-Prefix and/or		5.1. MAG-to-HAAA Interface
	Framed-IPv4-Address AVPs. For example a local Diameter proxy MAY add
	those in order to advertise locally available prefixes and addresses
	as well [I-D.damic-netlmm-pmip6-ind-discover]. It is also possible
	that PMIPv6 mobility support is not allowed for a subscription. In
	this case, a MAG may still provide normal IP connectivity to the MN
	using, for example, local address pools.
	5.2. Accounting at MAG		This specification does not define a new Application-ID for the MAG-
			to-HAAA Diameter connection. Rather, this specification re-uses any
			Diameter application and their commands that are used to authenticate
			and authorize the MN for the network access. Example applications
			include NASREQ [RFC4005] and EAP [RFC4072]. The MAG acts as a
			Diameter client.
	The accounting at the MAG to HAAA interface is based on the		The MAG-to-HAAA interactions are primarily used for bootstrapping
	[RFC4005]. The application identifier used for accounting is the		PMIPv6 mobility service session when a MN attaches and authenticates
	Diameter Base Accounting (3) [RFC3588].		to a PMIPv6 Domain. This includes the bootstrapping of PMIPv6
			session related information. The same interface may also be used for
			accounting.
	TBD.		Whenever the MAG sends a Diameter request message to the HAAA the
			User-Name AVP SHOULD contain the MN's identity. The MN identity, if
			available, MUST be in Network Access Identifier (NAI) [RFC4282]
			format. At minimum the home realm of the MN MUST be available at the
			MAG when the network access authentication takes place. Otherwise
			the MAG is not able to route the Diameter request messages towards
			the correct HAAA. The MN identity used on the MAG-to-HAAA interface
			and in the User-Name AVP MAY entirely be related to the network
			access authentication, and therefore not suitable to be used as the
			MN-ID mobility option value in the subsequent PBU/PBA messages. See
			the related discussion on MN's identities in Section 4.6 and in
			Section 5.2.1
	6. LMA to HAAA Interface Application Support		For the session management and service authorization purposes,
			session state SHOULD be maintained on the MAG-to-HAAA interface. See
			the discussion in Section 4.8.
	6.1. Application Support and Command Codes		5.2. LMA-to-HAAA Interface
	The LMA to HAAA interface may be used for multiple purposes. These		The-LMA-to HAAA interface may be used for multiple purposes. These
	include the authorization of the incoming PBU, possible PMIPv6		include the authorization of the incoming PBU, updating the LMA
	security related information retrieval, accounting and PMIPv6 session		address to the HAAA, accounting and PMIPv6 session management.
	management.
	This specification defines a new Application-ID for the LMA to HAAA		This specification does not define a new Application-ID for the LMA-
	interface and specifically for the authorization of the Proxy Binding		to-HAAA Diameter connection. Rather, this specification re-uses any
	Updates. The new application identifier is TBD BY IANA. The new		Diameter application and their commands. An example application
	application also defines two new commands and respective Command		could be NASREQ [RFC4005]. The LMA acts as a Diameter client.
	Codes: LHA-Request (value of TBD) and LHA-Answer (value of TBD). The
	LMA acts as a Diameter client.
	6.2. Authorization of the Proxy Binding Update		5.2.1. Authorization of the Proxy Binding Update
	Whenever the LMA sends a Diameter request message to the HAAA, the		Whenever the LMA sends a Diameter request message to the HAAA, the
	User-Name AVP MUST contain the MN identity. The identity MUST be in		User-Name AVP SHOULD contain the MN's identity. The LMA MAY retrieve
	a NAI format. The LMA MAY retrieve the MN identity information from		the MN's identity information from the PBU MN-ID [RFC4283][RFC5213]
	the PBU MN-ID [RFC4283][RFC5213] mobility option. The identity		mobility option. The identity SHOULD be the same as used on the MAG-
	SHOULD be the same as used on the MAG to HAAA interface, but in a		to-HAAA interface, but in the case those identities differ the HAAA
	case those identities differ the HAAA MUST have a mechanism of		MUST have a mechanism of mapping the MN identity used on the MAG-to-
	mapping the MN identity used on the MAG to HAAA interface to the		HAAA interface to the identity used on the LMA-to-HAAA interface.
	identity used on the LMA to HAAA interface.
	If the PBU contains the MN Link-Layer Identifier option, the Calling-		If the PBU contains the MN Link-Layer Identifier option, the Calling-
	Station-Id AVP SHOULD be included in the request message containing		Station-Id AVP SHOULD be included in the request message containing
	the received Link-Layer Identifier. Furthermore, if the PBU contains		the received Link-Layer Identifier. Furthermore, if the PBU contains
	the Service Selection mobility option [RFC5149], the Service-		the Service Selection mobility option [RFC5149], the Service-
	Selection AVP SHOULD be included in the request message containing		Selection AVP SHOULD be included in the request message containing
	the received service identifier.		the received service identifier.
	The LMA and the HAAA use the PMIP6-Home-Prefix AVP to exchange the		The LMA and the HAAA use the MIP6-Home-Link-Prefix AVP to exchange
	MN-HNP when appropriate. The low 64 bits of the prefix must be all		the MN-HNP when appropriate. Similarly, the LMA and the HAAA use the
	zeroes. Similarly, the LMA and the HAAA use the PMIP6-IPv4-Home-		PMIP6-IPv4-Home-Address AVP to exchange the IPv4-MN-HoA when
	Address AVP to exchange the MN IPv4-HoA when appropriate. If the		appropriate. Note that these AVPs are encapsulated inside the MIP6-
	PMIP6-Home-Prefix is set to an all zeroes address (i.e., 0::0) in the		Agent-Info AVP. Which entity is actually responsible for the address
	request message, it is an indication that the HAAA needs to assign		management is a deployment specific within the PMIPv6 Domain and MUST
	the MN-HNP and return it to the LMA in the response message. If the		be pre-agreed on per deployment basis.
	PMIP6-IPv4-Home-Address is set to all zeroes (i.e., 0.0.0.0) in the
	request message, it is an indication that the HAAA needs to assign
	the MN IPv4-HoA and return it to the LMA in the response message.
	The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY.		The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY.
	If the HAAA is not able to authorize the subscriber's mobility		If the HAAA is not able to authorize the subscriber's mobility
	service session, then the reply message to the LMA MUST have the		service session, then the reply message to the LMA MUST have the
	Result-Code AVP set to value DIAMETER_PMIP6_AUTHORIZATION_FAILED (TBD		Result-Code AVP set to value DIAMETER_PMIP6_AUTHORIZATION_FAILED
	BY IANA) indicating a permanent failure.		(TBD5) indicating a permanent failure.
	The LMA to HAAA interface can also be used to update the selected LMA
	address to the HAAA. This applies to the case where the MAG, for
	example, discovers the LMA address using the DNS.
	6.2.1. LHA-Request
	The LHA-Request (LHAR, value of TBD) message is sent by the LMA to
	the Diameter server to initiate a mobility service session
	authorization procedure. The LHAR message format is defined below:
	<LHA-Request> ::= < Diameter Header: TBD, REQ, PXY >
	< Session-ID >
	{ Auth-Application-Id }
	{ User-Name }
	{ Destination-Realm }
	{ Origin-Host }
	{ Origin-Realm }
	{ Auth-Request-Type }
	[ Destination-Host ]
	[ Origin-State-Id ]
	[ NAS-Identifier ]
	[ NAS-IP-Address ]
	[ NAS-IPv6-Address ]
	[ NAS-Port-Type ]
	[ Called-Station-Id ]
	[ Calling-Station-Id ]
	{ MIP6-Feature-Vector }
	{ MIP6-Agent-Info }
	* [ PMIP6-Home-Prefix ]
	[ PMIP6-IPv4-Home-Address ]
	[ Service-Selection ]
	[ Authorization-Lifetime ]
	[ Auth-Session-State ]
	* [ Proxy-Info ]
	* [ Route-Record ]
	* [ AVP ]
	6.2.2. LHA-Answer
	The LHA-Answer (LHAA, value of TBD) message is sent in response to
	the LHA-Request (LHAR) message. If the mobility service session
	authorization procedure was successful then the response MAY include
	PMIPv6 LMA to HAAA interface AVPs. The PMIP6-Home-Prefix AVP
	contains MN-HNP and the PMIP6-IPv4-Home-Address AVP contains IPv4-
	HoA, if such information are needed. The LHAA message format is
	defined below:
	<LHA-Answer> ::= < Diameter Header: TBD, PXY >
	< Session-Id >
	{ Auth-Application-Id }
	{ Result-Code }
	{ Origin-Host }
	{ Origin-Realm }
	{ Auth-Request-Type }
	[ User-Name ]
	[ Authorization-Lifetime ]
	[ Auth-Session-State ]
	[ Error-Message ]
	[ Error-Reporting-Host ]
	[ Re-Auth-Request-Type ]
	[ MIP6-Feature-Vector ]
	* [ PMIP6-Home-Prefix ]
	[ PMIP6-IPv4-Home-Address ]
	[ Session-Timeout ]
	[ Chargeable-User-Identity ]
	[ Origin-State-Id ]
	* [ Proxy-Info ]
	* [ Redirect-Host ]
	[ Redirect-Host-Usage ]
	[ Redirect-Max-Cache-Time ]
	* [ Failed-AVP ]
	* [ AVP ]
	6.3. Accounting at LMA
	The accounting at the LMA to HAAA interface is based on the		The LMA-to-HAAA interface can also be used to update the selected LMA
	[RFC4005]. The application identifier used for accounting is the		address to the HAAA and the remote policy store during the
	Diameter Base Accounting (3) [RFC3588].		authorization step. This applies to the case where the MAG, for
			example, discovered the LMA address using the DNS.
	TBD.		6. Proxy Mobile IPv6 Session Management
	7. Proxy Mobile IPv6 Session Management		Concerning a PMIPv6 mobility session, the HAAA, the MAG and the LMA
			Diameter entities SHOULD be stateful and maintain the corresponding
			Authorization Session State Machine defined in [RFC3588]. If a state
			is maintained, then a PMIPv6 mobility session that can be identified
			by any of the Binding Cache (BCE) Lookup Keys described in RFC 5213
			(see Sections 5.4.1.1., 5.4.1.2. and 5.4.1.3.) MUST map to a single
			Diameter Session-Id. If the PMIPv6 Domain allows further separation
			of sessions, for example, identified by the RFC 5213 BCE Lookup Keys
			and the service selection combination (see Section 4.8 and
			[RFC5149]), then a single Diameter Session-Id MUST map to a PMIPv6
			mobility session identified by the RFC 5213 BCE Lookup Keys and the
			selected service.
	Concerning a PMIPv6 session, the HAAA MAY maintain a state. The LMA		If both the MAG-to-HAAA and the LMA-to-HAAA interfaces are deployed
	and the MAG MUST support the Authorization Session State Machine		in a PMIPv6 Domain, and a state is maintained on both interfaces,
	defined in [RFC3588]. Diameter session termination related commands		then one PMIPv6 mobility session would have two distinct Diameter
	described in the following sections may be exchanged between the LMA		sessions on the HAAA. The HAAA needs to be aware of this deployment
	and the HAAA.		possibility and SHOULD allow multiple Diameter sessions for the same
			PMIPv6 mobility session.
	The actual PMIPv6 session termination procedures take place at PMIPv6		Diameter session termination related commands described in the
	protocol level and are out of scope of this document.		following sections may be exchanged between the LMA and the HAAA, or
			between the MAG and the HAAA. The actual PMIPv6 session termination
			procedures take place at PMIPv6 protocol level and are described in
			more detail in RFC 5213 and [I-D.ietf-mext-binding-revocation].
	7.1. Session-Termination-Request		6.1. Session-Termination-Request
	The LMA or the MAG MAY send the Session-Termination-Request (STR)		The LMA or the MAG MAY send the Session-Termination-Request (STR)
	command [RFC3588] to the HAAA and inform the termination of an		command [RFC3588] to the HAAA and inform the termination of an
	ongoing PMIPv6 session is in progress.		ongoing PMIPv6 session is in progress.
	7.2. Session-Termination-Answer		6.2. Session-Termination-Answer
	The Session-Termination-Answer (STA) [RFC3588] is sent by the HAAA to		The Session-Termination-Answer (STA) [RFC3588] is sent by the HAAA to
	acknowledge the termination of a PMIPv6 session.		acknowledge the termination of a PMIPv6 session.
	7.3. Abort-Session-Request		6.3. Abort-Session-Request
	The HAAA MAY send the Abort-Session-Request (ACR) command [RFC3588]		The HAAA MAY send the Abort-Session-Request (ASR) command [RFC3588]
	to the LMA or to the MAG and request termination of a PMIPv6 session.		to the LMA or to the MAG and request termination of a PMIPv6 session.
	7.4. Abort-Session-Answer		6.4. Abort-Session-Answer
	The Abort-Session-Answer (ASA) command [RFC3588]is sent by the LMA or		The Abort-Session-Answer (ASA) command [RFC3588]is sent by the LMA or
	the MAG to acknowledge that the termination of a PMIPv6 session.		the MAG to acknowledge that the termination of a PMIPv6 session.
	8. Attribute Value Pair Occurrence Tables		7. Attribute Value Pair Occurrence Tables
	The following tables list the PMIPv6 MAG to HAAA interface and LMA to		The following tables list the PMIPv6 MAG-to-HAAA interface and LMA-
	HAAA interface AVPs including those that are defined in		to-HAAA interface AVPs including those that are defined in [RFC5447].
	[I-D.ietf-dime-mip6-integrated].
	The Figure 2 contains the AVPs and their occurrences on the MAG to		The Figure 2 contains the AVPs and their occurrences on the MAG-to-
	HAAA interface. The AVPs that are part of grouped AVP are not listed		HAAA interface. The AVPs that are part of grouped AVP are not listed
	in the table, rather only the grouped AVP is listed.		in the table, rather only the grouped AVP is listed.
	8.1. MAG to HAAA Interface		7.1. MAG-to-HAAA Interface
	+---------------+		+---------------+
	| Command-Code |		| Command-Code |
	|-------+-------+		|-------+-------+
	Attribute Name | REQ | ANS |		Attribute Name | REQ | ANS |
	-------------------------------+-------+-------+		-------------------------------+-------+-------+
	PMIP6-DHCP-Address | 0 | 0+ |		PMIP6-DHCP-Server-Address | 0 | 0+ |
	MIP6-Agent-Info | 0 | 0+ |		MIP6-Agent-Info | 0+ | 0+ |
	MIP6-Feature-Vector | 0-1 | 0-1 |		MIP6-Feature-Vector | 0-1 | 0-1 |
	PMIP6-IPv4-Home-Address | 0 | 0-1 |
	PMIP6-Home-Prefix | 0 | 0+ |
	Mobile-Node-Identifier | 0-1 | 0-1 |		Mobile-Node-Identifier | 0-1 | 0-1 |
	Calling-Station-Id | 0-1 | 0 |		Calling-Station-Id | 0-1 | 0 |
			Service-Selection | 0-1 | 0 |
			Service-Configuration | 0 | 0+ |
	+-------+-------+		+-------+-------+
	Figure 2: MAG to HAAA Interface Generic Diameter Request and Answer		Figure 2: MAG-to-HAAA Interface Generic Diameter Request and Answer
	Commands AVPs		Commands AVPs
	The following table describes the Diameter AVPs code values, types,		7.2. LMA-to-HAAA Interface
	possible flag values, and whether the AVP MAY be encrypted. The
	Diameter base protocol specification [RFC3588] specifies the AVP
	Flags rules for AVPs in section 4.5. Due to space constraints, the
	short form DiamIdent is used to represent DiameterIdentity and
	OctetStr is used to represent OctetString.
	+--------------------+
	| AVP Flag rules |
	+----+----+----+-----+----+
	AVP Section | | |SHLD|MUST | |
	Attribute Name Code Defined Data Type |MUST| MAY|NOT |NOT |Encr|
	------------------------------------------+----+----+----+-----+----+
	MIP6-Agent-Info TBD 4.1 Grouped | | P | | M,V | Y |
	PMIP6-IPv4-Home- | | | | | |
	Address TBD 4.2 Address | | P | | M,V | Y |
	PMIP6-DHCP-Address TBD 4.3 Address | | P | | M,V | Y |
	PMIP6-Home-Prefix TBD 4.4 Address | | P | | M,V | Y |
	MIP6-Feature- | | | | | |
	Vector TBD 4.5 Unsigned64| | P | | M,V | Y |
	Calling-Station-Id 31 4.7 UTF8String| | P | | M,V | Y |
	Mobile-Node- | | | | | |
	Identifier TBD 4.6 UTF8String| | P | | M,V | Y |
	------------------------------------------+----+----+----+-----+----+
	Figure 3: AVP Flag Rules Table
	8.2. LMA to HAAA Interface
	The AVP occurrences are defined in the ABNFs for the LHA-Request (see
	Section 6.2.1) and LHA-Answer (see Section 6.2.2) commands.
	The following table describes the Diameter AVPs code values, types,
	possible flag values, and whether the AVP MAY be encrypted. The
	Diameter base protocol specification [RFC3588] specifies the AVP
	Flags rules for AVPs in section 4.5. Due to space constraints, the
	short form DiamIdent is used to represent DiameterIdentity and
	OctetStr is used to represent OctetString.
	+--------------------+		+---------------+
	| AVP Flag rules |		| Command-Code |
	+----+----+----+-----+----+		|-------+-------+
	AVP Section | | |SHLD|MUST | |		Attribute Name | REQ | ANS |
	Attribute Name Code Defined Data Type |MUST| MAY|NOT |NOT |Encr|		-------------------------------+-------+-------+
	------------------------------------------+----+----+----+-----+----+		MIP6-Agent-Info | 0-1 | 0-1 |
	MIP6-Agent-Info TBD 4.1 Grouped | M | P | | V | Y |		MIP6-Feature-Vector | 0-1 | 0-1 |
	PMIP6-IPv4-Home- | | | | | |		Calling-Station-Id | 0-1 | 0 |
	Address TBD 4.2 Address | M | P | | V | Y |		Service-Selection | 0-1 | 0-1 |
	PMIP6-Home-Prefix TBD 4.4 Address | M | P | | V | Y |		User-Name | 0-1 | 0-1 |
	MIP6-Feature- | | | | | |		+-------+-------+
	Vector TBD 4.5 Unsigned64| M | P | | V | Y |
	Calling-Station-Id 31 4.7 UTF8String| M | P | | V | Y |
	Service-Selection TBD 4.8 UTF8String| M | P | | V | Y |
	Session-Timeout 27 4.9 Unsigned32| M | P | | V | Y |
	------------------------------------------+----+----+----+-----+----+
	Figure 4: AVP Flag Rules Table		Figure 3: LMA-to-HAAA Interface Generic Diameter Request and Answer
			Commands AVPs
	9. IANA Considerations		8. IANA Considerations
	9.1. Attribute Value Pair Codes		8.1. Attribute Value Pair Codes
	This specification defines the following new AVPs:		This specification defines the following new AVPs:
	PMIP6-DHCP-Address is set to TBD		PMIP6-DHCP-Server-Address is set to TBD1
	PMIP6-Home-Prefix is set to TBD		PMIP6-IPv4-Home-Address is set to TBD2
	PMIP6-IPv4-Home-Address is set to TBD		Mobile-Node-Identifier is set to TBD3
	Mobile-Node-Identifier is set to TBD		Service-Configuration is set to TBD4
	9.2. Namespaces		8.2. Namespaces
	This specification defines new values to the Mobility Capability		This specification defines new values to the Mobility Capability
	registry (see [I-D.ietf-dime-mip6-integrated]) for use with the MIP6-		registry (see [RFC5447]) for use with the MIP6-Feature-Vector AVP:
	Feature-Vector AVP:
	Token | Value | Description		Token | Value | Description
	---------------------------------+----------------------+------------		---------------------------------+----------------------+------------
	PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD]		PMIP6_SUPPORTED | 0x0000010000000000 | [RFC TBD]
	IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD]		IP4_HOA_SUPPORTED | 0x0000020000000000 | [RFC TBD]
	LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD]		LOCAL_MAG_ROUTING_SUPPORTED | 0x0000040000000000 | [RFC TBD]
	9.3. Application Identifiers		8.3. Result-Code AVP Values
	This specification requires IANA to allocate a new value for
	"Diameter Proxy Mobile IPv6" (PMIP6) from the Application Identifier
	namespace defined in [RFC3588].
	9.4. Command Codes
	IANA is requested to allocate new command code values for the
	following new commands from the Command Code namespace defined in
	[RFC3588].
	Command Code | Value
	-----------------------------------+------
	LHA-Request (LHAR) | TBD
	LHA-Answer (LHAA) | TBD
	9.5. Result-Code AVP Values
	This specification requests IANA to allocate a new value to the		This specification requests IANA to allocate a new value to the
	Result-Code AVP (AVP Code 268) address space within the Permanent		Result-Code AVP (AVP Code 268) address space within the Permanent
	Failures category (5xxx) defined in [RFC3588]:		Failures category (5xxx) defined in [RFC3588]:
	DIAMETER_PMIP6_AUTHORIZATION_FAILED is set to TBD		DIAMETER_PMIP6_AUTHORIZATION_FAILED is set to TBD5
	10. Security Considerations		9. Security Considerations
	The security considerations of the Diameter Base protocol [RFC3588],		The security considerations of the Diameter Base protocol [RFC3588],
	Diameter EAP application [RFC4072], Diameter NASREQ application		Diameter EAP application [RFC4072], Diameter NASREQ application
	[RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping		[RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping
	[I-D.ietf-dime-mip6-integrated] are applicable to this document.		[RFC5447] are applicable to this document.
	In general, the Diameter messages may be transported between the HA		In general, the Diameter messages may be transported between the HA
	and the Diameter server via one or more AAA brokers or Diameter		and the Diameter server via one or more AAA brokers or Diameter
	agents. In this case the HA to the Diameter server AAA communication		agents. In this case the HA to the Diameter server AAA communication
	rely on the security properties of the intermediate AAA brokers and		rely on the security properties of the intermediate AAA brokers and
	Diameter agents (such as proxies).		Diameter agents (such as proxies).
	11. Acknowledgements		10. Acknowledgements
	Jouni Korhonen would like to thank TEKES MERCoNe project for
	providing funding to work on this document while he was with
	TeliaSonera.
	12. References		Jouni Korhonen would like to thank the TEKES GIGA program MERCoNe-
			project for providing funding to work on this document while he was
			with TeliaSonera.
	12.1. Normative References		11. References
	[I-D.ietf-dime-mip6-integrated]		11.1. Normative References
	Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
	and K. Chowdhury, "Diameter Mobile IPv6: Support for
	Network Access Server to Diameter Server Interaction",
	draft-ietf-dime-mip6-integrated-12 (work in progress),
	January 2009.
	[I-D.ietf-netlmm-pmip6-ipv4-support]		[I-D.ietf-netlmm-pmip6-ipv4-support]
	Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy		Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
	Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-07		Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
	(work in progress), December 2008.		(work in progress), January 2009.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,		[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
	"Diameter Network Access Server Application", RFC 4005,		"Diameter Network Access Server Application", RFC 4005,
	August 2005.		August 2005.
	skipping to change at page 19, line 47		skipping to change at page 16, line 32
	[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	August 2005.		August 2005.
	[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The		[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
	Network Access Identifier", RFC 4282, December 2005.		Network Access Identifier", RFC 4282, December 2005.
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,		[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.		and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
	12.2. Informative References		[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
			and K. Chowdhury, "Diameter Mobile IPv6: Support for
			Network Access Server to Diameter Server Interaction",
			RFC 5447, February 2009.
	[I-D.damic-netlmm-pmip6-ind-discover]		11.2. Informative References
	Damic, D., Premec, D., Patil, B., Sahasrabudhe, M., and S.
	Krishnan, "Proxy Mobile IPv6 indication and discovery",
	draft-damic-netlmm-pmip6-ind-discover-03 (work in
	progress), February 2008.
	[I-D.ietf-dime-mip6-split]		[I-D.ietf-dime-mip6-split]
	Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,		Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
	and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home		and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
	Agent to Diameter Server Interaction",		Agent to Diameter Server Interaction",
	draft-ietf-dime-mip6-split-16 (work in progress),		draft-ietf-dime-mip6-split-16 (work in progress),
	December 2008.		December 2008.
			[I-D.ietf-mext-binding-revocation]
			Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
			and P. Yegani, "Binding Revocation for IPv6 Mobility",
			draft-ietf-mext-binding-revocation-03 (work in progress),
			January 2009.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.		[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
	Chowdhury, "Mobile Node Identifier Option for Mobile IPv6		Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
	(MIPv6)", RFC 4283, November 2005.		(MIPv6)", RFC 4283, November 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.
	[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service		[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
	Selection for Mobile IPv6", RFC 5149, February 2008.		Selection for Mobile IPv6", RFC 5149, February 2008.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen (editor)		Jouni Korhonen (editor)
	Nokia Siemens Network		Nokia Siemens Network
	Linnoitustie 6		Linnoitustie 6
	Espoo FIN-02600		Espoo FI-02600
	Finland		Finland
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Julien Bournelle		Julien Bournelle
	Orange Labs		Orange Labs
	38-4O rue du general Leclerc		38-4O rue du general Leclerc
	Issy-Les-Moulineaux 92794		Issy-Les-Moulineaux 92794
	France		France
	Email: julien.bournelle@orange-ftgroup.com		Email: julien.bournelle@orange-ftgroup.com
	Ahmad Muhanna
	Nortel
	2221 Lakeside Blvd.
	Richardson, TX 75082
	USA
	Email: amuhanna@nortel.com
	Kuntal Chowdhury		Kuntal Chowdhury
	Starent Networks		Starent Networks
	30 International Place		30 International Place
	Tewksbury MA 01876		Tewksbury MA 01876
	USA		USA
	Email: kchowdhury@starentnetworks.com		Email: kchowdhury@starentnetworks.com
			Ahmad Muhanna
			Nortel
			2221 Lakeside Blvd.
			Richardson, TX 75082
			USA
			Email: amuhanna@nortel.com
	Ulrike Meyer		Ulrike Meyer
	RWTH Aachen		RWTH Aachen
	Email: meyer@umic.rwth-aachen.de		Email: meyer@umic.rwth-aachen.de
End of changes. 109 change blocks.
	489 lines changed or deleted		368 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/