< draft-ietf-mip6-radius-01.txt		draft-ietf-mip6-radius-02.txt >
	Network Working Group K. Chowdhury		Network Working Group K. Chowdhury
	Internet-Draft Starent Networks		Internet-Draft Starent Networks
	Intended status: Standards Track A. Lior		Intended status: Standards Track A. Lior
	Expires: April 28, 2007 Bridgewater Systems		Expires: September 8, 2007 Bridgewater Systems
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	October 25, 2006		March 7, 2007
	RADIUS Mobile IPv6 Support		RADIUS Mobile IPv6 Support
	draft-ietf-mip6-radius-01.txt		draft-ietf-mip6-radius-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 April 28, 2007.		This Internet-Draft will expire on September 8, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	A Mobile IPv6 node requires a home agent(HA) address, a home		A Mobile IPv6 node requires a home agent(HA) address, a home
	address(HOA), and IPsec security association with its HA before it		address(HOA), and IPsec security association with its HA before it
	can start utilizing Mobile IPv6 service. RFC 3775 requires that some		can start utilizing Mobile IPv6 service. RFC 3775 requires that some
	or all of these parameters are statically configured. Ongoing work		or all of these parameters are statically configured. Ongoing work
	aims to make this information dynamically available to the mobile		aims to make this information dynamically available to the mobile
	node. An important aspect of the Mobile IPv6 bootstrapping solution		node. An important aspect of the Mobile IPv6 bootstrapping solution
	is to support interworking with existing authentication,		is to support interworking with existing authentication,
	skipping to change at page 3, line 18 ¶		skipping to change at page 2, line 34 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6		3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6		3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6
	3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7
	4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9		4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9
	4.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9		4.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9
	4.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9		4.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9
	4.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9		4.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9
	4.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9		4.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9
	4.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 9		4.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 9
	5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 10		4.6. Use of existing RADIUS Attributes . . . . . . . . . . . . 9
	5.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 10		4.6.1. User-Name . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 11		4.6.2. Service-Type . . . . . . . . . . . . . . . . . . . . . 10
	5.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 11		4.6.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . 10
	5.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 12		4.6.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . 10
	5.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 13		4.6.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . 10
	6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 16		5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 11
	6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 16		5.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 11
	6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 16		5.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 12
	6.1.2. HA allocation in the ASP (visited network) . . . . . . 17		5.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 13
	6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 18		5.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 14
			5.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 15
			6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 17
			6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 17
			6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 17
			6.1.2. HA allocation in the ASP (visited network) . . . . . . 18
			6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 19
	6.2.1. Mobile Service Provider and Mobile Service		6.2.1. Mobile Service Provider and Mobile Service
	Authorizer are the same entity. . . . . . . . . . . . 18		Authorizer are the same entity. . . . . . . . . . . . 19
	6.2.2. Mobile Service Provider and Mobile Service		6.2.2. Mobile Service Provider and Mobile Service
	Authorizer are different entities. . . . . . . . . . . 20		Authorizer are different entities. . . . . . . . . . . 21
	7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 21		7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 22
	7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 21		7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 22
	7.2. Service Authorization . . . . . . . . . . . . . . . . . . 21		7.2. Service Authorization . . . . . . . . . . . . . . . . . . 22
	7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 22		7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 23
	7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 22		7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 23
	7.5. Provisioning of Configuration Parameters . . . . . . . . . 22		7.5. Provisioning of Configuration Parameters . . . . . . . . . 23
	8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23		8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 24
	9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 24		9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 25
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 25		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 28		13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	13.2. Informative References . . . . . . . . . . . . . . . . . . 28		13.2. Informative References . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	Intellectual Property and Copyright Statements . . . . . . . . . . 31		Intellectual Property and Copyright Statements . . . . . . . . . . 32
	1. Introduction		1. Introduction
	Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform		Mobile IPv6 specification [6] requires a Mobile Node (MN) to perform
	registration with a HA with information about its current point of		registration with an HA with information about its current point of
	attachment (Care-of Address). The HA creates and maintains binding		attachment (Care-of Address). The HA creates and maintains binding
	between the MN's HOA and the MN's Care-of Address.		between the MN's HOA and the MN's Care-of Address.
	In order to register with a HA, the MN needs to know some information		In order to register with a HA, the MN needs to know some information
	such as, the Home Link prefix, the HA Address, the HOA, the Home Link		such as, the Home Link prefix, the HA Address, the HOA, the Home Link
	prefix Length and security related information in order to secure the		prefix Length and security related information in order to secure the
	Binding Update.		Binding Update.
	The aforementioned set of information may be statically provisioned		The aforementioned set of information may be statically provisioned
	in the MN. However, static provisioning of this information has its		in the MN. However, static provisioning of this information has its
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	Dynamic assignment of Mobile IPv6 home registration information is a		Dynamic assignment of Mobile IPv6 home registration information is a
	desirable feature for ease of deployment and network maintenance.		desirable feature for ease of deployment and network maintenance.
	For this purpose, the RADIUS infrastructure, which is used for access		For this purpose, the RADIUS infrastructure, which is used for access
	authentication, can be leveraged to assign some or all of the		authentication, can be leveraged to assign some or all of the
	necessary parameters. The RADIUS server in the Access Service		necessary parameters. The RADIUS server in the Access Service
	Provider (ASP) or in the Mobility Service Provider's (MSP) network		Provider (ASP) or in the Mobility Service Provider's (MSP) network
	may return these parameters to the AAA client. The AAA client might		may return these parameters to the AAA client. The AAA client might
	either be the NAS, in case of the integrated scenario, or the HA, in		either be the NAS, in case of the integrated scenario, or the HA, in
	case of the split scenario. The terms integrated and split are		case of the split scenario. The terms integrated and split are
	described in the terminology section and were introduced in [6].		described in the terminology section and were introduced in [7].
	2. Terminology		2. Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "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 [1].		document are to be interpreted as described in [1].
	General mobility terminology can be found in [7]. The following		General mobility terminology can be found in [8]. The following
	additional terms, as defined in [6], are used in this document:		additional terms, as defined in [7], are used in this document:
	Access Service Authorizer (ASA):		Access Service Authorizer (ASA):
	A network operator that authenticates a MN and establishes the		A network operator that authenticates a MN and establishes the
	MN's authorization to receive Internet service.		MN's authorization to receive Internet service.
	Access Service Provider (ASP):		Access Service Provider (ASP):
	A network operator that provides direct IP packet forwarding to		A network operator that provides direct IP packet forwarding to
	and from the MN.		and from the MN.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	Integrated Scenario:		Integrated Scenario:
	A scenario where the mobility service and the network access		A scenario where the mobility service and the network access
	service are authorized by the same entity.		service are authorized by the same entity.
	3. Solution Overview		3. Solution Overview
	This document addresses the authentication, authorization and		This document addresses the authentication, authorization and
	accounting functionality required by for the MIPv6 bootstrapping as		accounting functionality required by for the MIPv6 bootstrapping as
	outlined in the MIPv6 bootstrapping problem statement document (see		outlined in the MIPv6 bootstrapping problem statement document (see
	[6]). As such, the AAA functionality for the integrated and the		[7]). As such, the AAA functionality for the integrated and the
	split scenario needs to be defined. This requires the ability to		split scenario needs to be defined. This requires the ability to
	offer support for the HA to AAA server and the network access server		offer support for the HA to AAA server and the network access server
	to AAA server communication.		to AAA server communication.
	To highlight the main use cases, we briefly describe the integrated		To highlight the main use cases, we briefly describe the integrated
	and the split scenarios in Section 3.1 and Section 3.2, respectively.		and the split scenarios in Section 3.1 and Section 3.2, respectively.
	3.1. Integrated Scenario		3.1. Integrated Scenario
	In the integrated scenario MIPv6 bootstrapping is provided as part of		In the integrated scenario MIPv6 bootstrapping is provided as part of
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	|(Mobility Service Provider)| | |		|(Mobility Service Provider)| | |
	| | | +-------+ |		| | | +-------+ |
	| +-------+ | | |Remote | |		| +-------+ | | |Remote | |
	| |Local | RADIUS | | |RADIUS | |		| |Local | RADIUS | | |RADIUS | |
	| |RADIUS |-------------------------|Server | |		| |RADIUS |-------------------------|Server | |
	| |Proxy | | | +-------+ |		| |Proxy | | | +-------+ |
	| +-------+ | | ^ |		| +-------+ | | ^ |
	| ^ ^ | | |RADIUS |		| ^ ^ | | |RADIUS |
	| | | | | | |		| | | | | | |
	| | | | | v |		| | | | | v |
	| |RADIUS | | +-------+ |		| RADIUS| | | +-------+ |
	| | | +-------+ | | |Local | |		| | | +-------+ | | |Local | |
	| | | RADIUS |Home | | | |Home | |		| | | RADIUS |Home | | | |Home | |
	| | +------->|Agent | | | |Agent | |		| | +------->|Agent | | | |Agent | |
	| | |in ASP | | | +-------+ |		| | |in ASP | | | +-------+ |
	| v +-------+ | +-----------------+		| v +-------+ | +-----------------+
	+-------+ IEEE | +-----------+ +-------+ |		+-------+ IEEE | +-----------+ +-------+ |
	|Mobile | 802.1X | |NAS / Relay| |DHCPv6 | |		|Mobile | 802.1X | |NAS / Relay| |DHCPv6 | |
	|Node |----------+-|RADIUS |---|Server | |		|Node |----------+-|RADIUS |---|Server | |
	| | PANA,... | |Client | | | |		| | PANA,... | |Client | | | |
	+-------+ DHCP | +-----------+ +-------+ |		+-------+ DHCP | +-----------+ +-------+ |
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	In the split scenario, Mobile IPv6 bootstrapping is not provided as		In the split scenario, Mobile IPv6 bootstrapping is not provided as
	part of the network access authentication procedure. The Mobile IPv6		part of the network access authentication procedure. The Mobile IPv6
	bootstrapping procedure is executed with the Mobility Service		bootstrapping procedure is executed with the Mobility Service
	Provider when desired by the MN. Two variations can be considered:		Provider when desired by the MN. Two variations can be considered:
	1. the MSA and the MSP are the same entity.		1. the MSA and the MSP are the same entity.
	2. the MSA and the MSP are different entities.		2. the MSA and the MSP are different entities.
	Since scenario (1) is the more generic scenario we show it in		Since scenario (2) is the more generic scenario we show it in
	Figure 2.		Figure 2.
	+----------------------+		+----------------------+
	| |		| |
	|Mobility +-------+ |		|Mobility +-------+ |
	|Service |Remote | |		|Service |Remote | |
	|Authorizer |RADIUS | |		|Authorizer |RADIUS | |
	|(MSA) |Server | |		|(MSA) |Server | |
	| +-------+ |		| +-------+ |
	+---------------^------+		+---------------^------+
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	|Node |-------------|RADIUS |-------------- |RADIUS | |		|Node |-------------|RADIUS |-------------- |RADIUS | |
	| | IKEv2 | |Client | |Proxy | |		| | IKEv2 | |Client | |Proxy | |
	+-------+ | +-----------+ +-------+ |		+-------+ | +-----------+ +-------+ |
	+----------------------------------------+		+----------------------------------------+
	Figure 2: Mobile IPv6 service access in the split scenario (MSA !=		Figure 2: Mobile IPv6 service access in the split scenario (MSA !=
	MSP)		MSP)
	As shown in Figure 2 the interaction between the RADIUS client and		As shown in Figure 2 the interaction between the RADIUS client and
	the RADIUS server is triggered by the protocol interaction between		the RADIUS server is triggered by the protocol interaction between
	the MN and the HA/RADIUS client using IKEv2 (see [3] and [8]). The		the MN and the HA/RADIUS client using IKEv2 (see [3] and [9]). The
	HA / RADIUS Client interacts with the RADIUS infrastructure to		HA / RADIUS Client interacts with the RADIUS infrastructure to
	perform authentication, authorization, accounting and parameter		perform authentication, authorization, accounting and parameter
	bootstrapping. The exchange is triggered by the home agent and an		bootstrapping. The exchange is triggered by the HA and an
	interaction with the RADIUS infrastructure is initiated. When the		interaction with the RADIUS infrastructure is initiated. When the
	protocol exchange is completed then the HA needs to possess the		protocol exchange is completed then the HA needs to possess the
	Mobile IPv6 specific parameters (see [6]).		Mobile IPv6 specific parameters (see [7]).
	Additionally, the MN might instruct the RADIUS server (via the home		Additionally, the MN might instruct the RADIUS server (via the HA) to
	agent) to perform a dynamic DNS update.		perform a dynamic DNS update.
	4. RADIUS Attribute Overview		4. RADIUS Attribute Overview
	4.1. MIP6-HA Attribute		4.1. MIP6-HA Attribute
	The RADIUS server may decide to assign a HA to the MN that is in		The RADIUS server may decide to assign a HA to the MN that is in
	close proximity to the point of attachment (e.g., determined by the		close proximity to the point of attachment (e.g., as determined by
	NAS-ID). There may be other reasons for dynamically assigning HAs to		the NAS-ID). There may be other reasons for dynamically assigning
	the MN, for example to share the traffic load. The attribute also		HAs to the MN, for example to share the traffic load. The attribute
	contains the prefix length so that the MN can easily infer the Home		also contains the prefix length so that the MN can easily infer the
	Link prefix from the HA address.		Home Link prefix from the HA address.
	4.2. MIP6-HA-FQDN Attribute		4.2. MIP6-HA-FQDN Attribute
	The RADIUS server may assign an FQDN of the HOA to the MN. The		The RADIUS server may assign an FQDN of the HA to the MN. The mobile
	mobile node can perform DNS query with the FQDN to derive the HA		node can perform DNS query with the FQDN to derive the HA address.
	address.
	4.3. MIP6-HL-Prefix Attribute		4.3. MIP6-HL-Prefix Attribute
	For the same reason as the HA assignment, the RADIUS server may		For the same reason as the HA assignment, the RADIUS server may
	assign a Home Link that is in close proximity to the point of		assign a Home Link that is in close proximity to the point of
	attachment (NAS-ID). The MN can perform [5] specific procedures to		attachment (NAS-ID). The MN can perform [6] specific procedures to
	discover other information for Mobile IPv6 registration.		discover other information for Mobile IPv6 registration.
	4.4. MIP6-HOA Attribute		4.4. MIP6-HOA Attribute
	The RADIUS server may assign a HOA to the MN. This allows the		The RADIUS server may assign a HOA to the MN. This allows the
	network operator to support mobile devices that are not configured		network operator to support mobile devices that are not configured
	with static addresses. The attribute also contains the prefix length		with static addresses. The attribute also contains the prefix length
	so that the MN can easily infer the Home Link prefix from the HA		so that the MN can easily infer the Home Link prefix from the HA
	address.		address.
	4.5. MIP6-DNS-MO Attribute		4.5. MIP6-DNS-MO Attribute
	By using this payload the RADIUS client instructs the RADIUS server		By using this payload the RADIUS client instructs the RADIUS server
	to perform a dynamic DNS update. When this payload is included in		to perform a dynamic DNS update. When this payload is included in
	the reverse direction, i.e., from the RADIUS server to the RADIUS		the reverse direction, i.e., from the RADIUS server to the RADIUS
	client, it informs about the status of the dynamic DNS update. When		client, it informs about the status of the dynamic DNS update. When
	the payload is sent from the RADIUS client to the RADIUS server then		the payload is sent from the RADIUS client to the RADIUS server then
	the response MUST include the MIP6-DNS-MO attribute.		the response MUST include the MIP6-DNS-MO attribute.
			4.6. Use of existing RADIUS Attributes
			4.6.1. User-Name
			If authentication via IKEv2 is used then the User-Name attribute
			SHALL be set to the IDi payload received in the IKE_AUTH exchange.
			4.6.2. Service-Type
			If the HA uses Service-Type(6) is SHALL set its value to "Framed"(2).
			4.6.3. NAS-Port-Type
			In order for the AAA to distingiues the source of the Access-Request
			NAS-Port-Type(61) is used as follows:
			In the split scenario when the Access-Request originates from an MIP6
			HA, NAS-Port-Type MUST be included and its value set to HA6(IANA-
			TBD1).
			4.6.4. Calling-Station-Id
			In the split-scenario, the HA SHOULD use the Calling-Station-Id(31)
			to send the MN's COA to the AAA. If used, the string value of the
			Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA.
			4.6.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key
			To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize
			the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [4]. The
			first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key,
			and the next up to 32 octets are stored into the MS-MPPE-Send-Key.
			The encryption of these attributes is described in [4].
	5. RADIUS attributes		5. RADIUS attributes
	This section defines format and syntax for the attribute that carries		This section defines format and syntax for the attribute that carries
	the Mobile IPv6 parameters that are described in the previous		the Mobile IPv6 parameters that are described in the previous
	section.		section.
	The attributes MAY be present in Access-Accept, Accounting-Request.		The attributes MAY be present in Access-Request, Access-Accept, and
			Accounting-Request packets.
	5.1. MIP6-HA Attribute		5.1. MIP6-HA Attribute
	This attribute is sent by the RADIUS server to the NAS in an Access-		One or more of this attribute is sent by the RADIUS server to the NAS
	Accept packet. The attribute carries the assigned HA address.		in an Access-Accept packet. The attribute carries the assigned HA
			address.
	This attribute MAY be sent by the NAS to the RADIUS server in an		This attribute MAY beMIP6-DNS-MO Attribute sent by the NAS to the
	Access-Request packet as a hint to suggest a dynamic HA that may be		RADIUS server in an Access-Request packet as a hint to suggest a
	assigned to the MN. The RADIUS server MAY use this value or may		dynamic HA that may be assigned to the MN. The RADIUS server MAY use
	ignore this suggestion.		this value or may ignore this suggestion.
	If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA-		If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA-
	FQDN SHOULD appear in accounting packets to indicate the identity of		FQDN SHOULD appear in accounting packets to indicate the identity of
	the serving HA for this session.		the serving HA for this session.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved | Prefix-Length |		| Type | Length | Reserved | Prefix-Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| IPv6 address of assigned HA |
	| |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 address of assigned HA |		| IPv6 address of assigned HA cont. |
	| |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| IPv6 address of assigned HA cont. |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 address of assigned HA cont. |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 address of assigned HA cont. |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 address of assigned HA cont. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		Type:
	ASSIGNED-HA-ADDR-TYPE to be defined by IANA.		ASSIGNED-HA-ADDR-TYPE to be defined by IANA.
	Length:		Length:
	= 20 octets		= 21 octets
	Reserved:		Reserved:
	Reserved for future use. The bits MUST be set to zero by the		Reserved for future use. The bits MUST be set to zero by the
	sender, and MUST be ignored by the receiver.		sender, and MUST be ignored by the receiver.
	Prefix-Length:		Prefix-Length:
	This field indicates the prefix length of the Home Link.		This field indicates the prefix length of the Home Link.
	IPv6 address of assigned HA:		IPv6 address of assigned HA:
	128-bit IPv6 address of the assigned HA.		128-bit IPv6 address of the assigned HA.
	5.2. MIP6-HA-FQDN Attribute		5.2. MIP6-HA-FQDN Attribute
	This attribute is sent by the RADIUS server to the NAS in an Access-		One or more of this attribute is sent by the RADIUS server to the NAS
	Accept packet. The attribute carries the FQDN of the assigned HA.		in an Access-Accept packet. The attribute carries the FQDN of the
			assigned HA.
	This attribute MAY be sent by the NAS to the RADIUS server in an		This attribute MAY be sent by the NAS to the RADIUS server in an
	Access-Request packet as a hint to suggest a dynamic HA that may be		Access-Request packet as a hint to suggest a dynamic HA that may be
	assigned to the MN. The RADIUS server MAY use this value or may		assigned to the MN. The RADIUS server MAY use this value or may
	ignore this suggestion.		ignore this suggestion.
	If available at the NAS, at least MIP6-HA-FQDN attribute and/or		If available at the NAS, at least MIP6-HA-FQDN attribute and/or
	MIP6-HA SHOULD appear in accounting packets to indicate the identity		MIP6-HA SHOULD appear in accounting packets to indicate the identity
	of the serving HA for this session.		of the serving HA for this session.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | FQDN of the assigned HA .....		| Type | Length | FQDN of the assigned HA .....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		Type:
	ASSIGNED-HA-FQDN-TYPE to be defined by IANA.		ASSIGNED-HA-FQDN-TYPE to be defined by IANA.
	Length:		Length:
	Variable length.		Variable length.
	FQDN of the assigned HA:		FQDN of the assigned HA:
	The data field MUST contain a FQDN as described in [9].		The data field MUST contain a FQDN as described in [10].
	5.3. MIP6-HL-Prefix Attribute		5.3. MIP6-HL-Prefix Attribute
	This attribute is sent by the RADIUS-MIP server to the NAS in an		This attribute is sent by the RADIUS-MIP server to the NAS in an
	Access-Accept packet. The attribute carries the assigned Home Link		Access-Accept packet. The attribute carries the assigned Home Link
	prefix.		prefix.
	This attribute MAY be sent by the NAS to the RADIUS server in an		This attribute MAY be sent by the NAS to the RADIUS server in an
	Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN		Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN
	attribute as a hint to suggest a Home Link prefix that may be		attribute as a hint to suggest a Home Link prefix that may be
	skipping to change at page 15, line 17 ¶		skipping to change at page 16, line 25 ¶
	Reserved-2:		Reserved-2:
	Reserved for future use. The bits MUST be set to zero by the		Reserved for future use. The bits MUST be set to zero by the
	sender, and MUST be ignored by the receiver.		sender, and MUST be ignored by the receiver.
	FQDN of the MN:		FQDN of the MN:
	In an Access-Request packet the data field MUST contain a FQDN.		In an Access-Request packet the data field MUST contain a FQDN.
	In an Access-Accept packet the data field MAY contain an FQDN.		In an Access-Accept packet the data field MAY contain an FQDN.
	FQDN is described in [9].		FQDN is described in [10].
	6. Message Flows		6. Message Flows
	6.1. Integrated Scenario (MSA=ASA)		6.1. Integrated Scenario (MSA=ASA)
	This section is based on [2] and uses the previously defined RADIUS		This section is based on [2] and uses the previously defined RADIUS
	attributes.		attributes.
	6.1.1. HA allocation in the MSP		6.1.1. HA allocation in the MSP
	skipping to change at page 17, line 7 ¶		skipping to change at page 18, line 7 ¶
	HA allocation in the MSP		HA allocation in the MSP
	In step (1), the MN executes the normal network access authentication		In step (1), the MN executes the normal network access authentication
	procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS		procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS
	acts as an authenticator in "pass-through" mode, i.e., the endpoint		acts as an authenticator in "pass-through" mode, i.e., the endpoint
	of the authentication dialogue is the MN's home RADIUS server. This		of the authentication dialogue is the MN's home RADIUS server. This
	is the typical scenario in case the messages involved in the		is the typical scenario in case the messages involved in the
	authentication protocol are transported in EAP.		authentication protocol are transported in EAP.
	As per [10], the NAS encapsulates/decapsulates EAP packets into/from		As per [11], the NAS encapsulates/decapsulates EAP packets into/from
	RADIUS packets until an Access-Response (either an Access-Accept or		RADIUS packets until an Access-Response (either an Access-Accept or
	an Access/Reject packet is received by the NAS). This concludes the		an Access/Reject packet is received by the NAS). This concludes the
	network access authentication phase.		network access authentication phase.
	Depending on the RADIUS server configuration, the MIP6-HA attribute		Depending on the RADIUS server configuration, the MIP6-HA attribute
	or the the MIP6-HA-FQDN attribute may be appended to the Access-		or the the MIP6-HA-FQDN attribute may be appended to the Access-
	Accept packet. In the latter case the MN needs to perform a DNS		Accept packet. In the latter case the MN needs to perform a DNS
	query in order to discover the HA address.		query in order to discover the HA address.
	The MIP6-HA or MIP6-HA-FQDN attribute is appended to the Access-		The MIP6-HA or MIP6-HA-FQDN attribute is appended to the Access-
	skipping to change at page 17, line 42 ¶		skipping to change at page 18, line 42 ¶
	message. This option carries the RADIUS MIP6-HA Attribute from the		message. This option carries the RADIUS MIP6-HA Attribute from the
	Access-Accept packet.		Access-Accept packet.
	In step (4), the DHCP server identifies the client (by DUID) and		In step (4), the DHCP server identifies the client (by DUID) and
	finds out that it requests HA information in the MSP (by the Home		finds out that it requests HA information in the MSP (by the Home
	Network Identifier Option = 1). The DHCP server extracts the HA		Network Identifier Option = 1). The DHCP server extracts the HA
	address from OPTION_MIP6-RELAY-Option and places it into Home Network		address from OPTION_MIP6-RELAY-Option and places it into Home Network
	Information Option in the Reply message.		Information Option in the Reply message.
	In step (5), the Relay Agent forwards the Reply Message to the MN.		In step (5), the Relay Agent forwards the Reply Message to the MN.
	On reception of this message, the HA address or the FQDN of the home		On reception of this message, the HA address or the FQDN of the HA is
	agent is available at the MN.		available at the MN.
	6.1.2. HA allocation in the ASP (visited network)		6.1.2. HA allocation in the ASP (visited network)
	This scenario is similar to the one described in Section 6.1.1. The		This scenario is similar to the one described in Section 6.1.1. The
	difference is in step (2), where the type-id field in the Home		difference is in step (2), where the type-id field in the Home
	Network Identifier Option is set to zero, indicating that a HA is		Network Identifier Option is set to zero, indicating that a HA is
	requested in the ASP instead of in the MSP. Thus, the information		requested in the ASP instead of in the MSP. Thus, the information
	received by the home RADIUS server, via the DHCP relay, in the		received by the home RADIUS server, via the DHCP relay, in the
	OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP		OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP
	server allocates a HA from its list of possible HAs and returns it in		server allocates a HA from its list of possible HAs and returns it in
	skipping to change at page 18, line 26 ¶		skipping to change at page 19, line 26 ¶
	In this scenario there is no relationship between the network access		In this scenario there is no relationship between the network access
	authentication procedure and the MIPv6 bootstrapping procedure.		authentication procedure and the MIPv6 bootstrapping procedure.
	In order to learn the IP address of the HA, the MN either performs a		In order to learn the IP address of the HA, the MN either performs a
	DNS lookup of the HA Name or a DNS lookup by service name. In the		DNS lookup of the HA Name or a DNS lookup by service name. In the
	first case, the MN is preconfigured with the FQDN of the HA, and thus		first case, the MN is preconfigured with the FQDN of the HA, and thus
	sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request		sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request
	for IPv6 address of HA). A DNS reply message is returned by the DNS		for IPv6 address of HA). A DNS reply message is returned by the DNS
	server with the HA address.		server with the HA address.
	The MN then runs IKEv2 [11] with the HA in order to set up IPsec SAs		The MN then runs IKEv2 [12] with the HA in order to set up IPsec SAs
	(MN-HA). As part of this,the MN authenticates itself to the RADIUS		(MN-HA). As part of this,the MN authenticates itself to the RADIUS
	server in the MSA domain, and obtains authorization for mobility		server in the MSA domain, and obtains authorization for mobility
	service (including the Home Address).		service (including the Home Address).
	The MN shares credentials with the RADIUS server in the MSA domain.		The MN shares credentials with the RADIUS server in the MSA domain.
	The RADIUS communication between the HA and the this RADIUS server is		The RADIUS communication between the HA and the this RADIUS server is
	also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP		also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP
	within IKEv2 [11], the MN is authenticated and authorized for the		within IKEv2 [12], the MN is authenticated and authorized for the
	IPv6 mobility service and is also assigned a HOA.		IPv6 mobility service and is also assigned a HOA.
	The setup of SAs and mutual authentication between MN and AAAH using		The setup of SAs and mutual authentication between MN and AAAH using
	RADIUS (and EAP) is similar to the one described for Diameter		RADIUS (and EAP) is similar to the one described for Diameter
	protocol in [12]. The described mechanism ensureas that common		protocol in [13]. The described mechanism ensureas that common
	keying material will be available at the MN and HA after successful		keying material will be available at the MN and HA after successful
	completion.		completion.
	----------------------------ASP--------->|<-----MSA/MSP		----------------------------ASP--------->|<-----MSA/MSP
	+----+ IKEv2 +----+ RADIUS (EAP) +--------------------+		+----+ IKEv2 +----+ RADIUS (EAP) +--------------------+
	| MN |<----------->| HA |<-------------------->|Remote RADIUS Server|		| MN |<----------->| HA |<-------------------->|Remote RADIUS Server|
	+----+ +----+ +--------------------+		+----+ +----+ +--------------------+
	MN HA Remote RADIUS server		MN HA Remote RADIUS server
	skipping to change at page 20, line 6 ¶		skipping to change at page 21, line 6 ¶
	HDR, SK{EAP-Success}		HDR, SK{EAP-Success}
	<-------------------------------		<-------------------------------
	HDR, SK{AUTH}		HDR, SK{AUTH}
	------------------------------->		------------------------------->
	HDR, SK {AUTH, SAr2, TSi, TSr }		HDR, SK {AUTH, SAr2, TSi, TSr }
	<-------------------------------		<-------------------------------
	Split Scenario Exchange		Split Scenario Exchange
	MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages		MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages
	defined in the IKEv2 specification [11], negotiating crypto		defined in the IKEv2 specification [12], negotiating crypto
	algorithms and running DH key exchange). IKEv2 supports integration		algorithms and running DH key exchange). IKEv2 supports integration
	with EAP. The MN indicates its desire to use EAP by not including		with EAP. The MN indicates its desire to use EAP by not including
	the AUTH payload in the third message. However, it indicates its		the AUTH payload in the third message. However, it indicates its
	identity (NAI) by using the IDi field. If the HA supports EAP for		identity (NAI) by using the IDi field. If the HA supports EAP for
	authentication, as per [10] it forwards the identity to the Remote		authentication, as per [11] it forwards the identity to the Remote
	RADIUS server by sending a RADIUS Access-Request packet containing		RADIUS server by sending a RADIUS Access-Request packet containing
	the identity in the EAP-Payload AVP and in the RADIUS User-Name		the identity in the EAP-Payload AVP and in the RADIUS User-Name
	attribute. Based on this identity, the Remote RADIUS server chooses		attribute. Based on this identity, the Remote RADIUS server chooses
	authentication method and sends the first EAP-Request in the RADIUS		authentication method and sends the first EAP-Request in the RADIUS
	Access-Challenge packet. During the EAP authentication phase, the HA		Access-Challenge packet. During the EAP authentication phase, the HA
	relays EAP packets between the MN and the Remote RADIUS server. If		relays EAP packets between the MN and the Remote RADIUS server. If
	the authentication succeeds and if the MN is authorized to use Mobile		the authentication succeeds and if the MN is authorized to use Mobile
	IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept		IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept
	packet containing the EAP-Success and the AAA-Key derived from the		packet containing the EAP-Success and the AAA-Key derived from the
	EAP authentication method. EAP authentication methods that do not		EAP authentication method. EAP authentication methods that do not
	skipping to change at page 21, line 8 ¶		skipping to change at page 22, line 8 ¶
	MSP#MSA Exchange		MSP#MSA Exchange
	The scenario is similar to previously described scenarios with the		The scenario is similar to previously described scenarios with the
	difference of utilizing AAA roaming agreements between the MSP and		difference of utilizing AAA roaming agreements between the MSP and
	the MSA.		the MSA.
	7. Goals for the HA-AAA Interface		7. Goals for the HA-AAA Interface
	Here, we follow the classification and labels listed in the MIPv6-		Here, we follow the classification and labels listed in the MIPv6-
	AAA-Goals document [13].		AAA-Goals document [14].
	7.1. General Goals		7.1. General Goals
	G1.1-G1.4 Security		G1.1-G1.4 Security
	These are standard requirements for a AAA protocol - mutual		These are standard requirements for a AAA protocol - mutual
	authentication, integrity, replay protection, confidentiality. IPsec		authentication, integrity, replay protection, confidentiality. IPsec
	can be used to achieve the goals. Goal G1.5 regarding inactive peer		can be used to achieve the goals. Goal G1.5 regarding inactive peer
	detection needs further investigations since heartbeat messages do		detection needs further investigations since heartbeat messages do
	not exist (like in the Diameter case, Watch-Dog-Request/Answer).		not exist (like in the Diameter case, Watch-Dog-Request/Answer).
	7.2. Service Authorization		7.2. Service Authorization
	G2.1. The AAA-HA interface should allow the use of Network Access		G2.1. The AAA-HA interface should allow the use of Network Access
	Identifier (NAI) to identify the MN. The User-Name attribute can be		Identifier (NAI) to identify the MN. The User-Name attribute can be
	used for the purpose to carry the NAI.		used for the purpose to carry the NAI.
	G2.2 The HA should be able to query the AAAH server to verify Mobile		G2.2 The HA should be able to query the AAAH server to verify Mobile
	IPv6 service authorization for the MN. Any node implementing RADIUS		IPv6 service authorization for the MN. Any node implementing RADIUS
	functionality[4] can possibly initiate a request message. In		functionality[5] can possibly initiate a request message. In
	combination with the ability of the RADIUS protocol to carry EAP		combination with the ability of the RADIUS protocol to carry EAP
	messages [10] , our solution will enable an HA to query a RADIUS		messages [11] , our solution will enable an HA to query a RADIUS
	server and verify MIPv6 authorization for the MN.		server and verify MIPv6 authorization for the MN.
	G2.3 The AAAH server should be able to enforce explicit operational		G2.3 The AAAH server should be able to enforce explicit operational
	limitations and authorization restrictions on the HA (e.g., packet		limitations and authorization restrictions on the HA (e.g., packet
	filters, QoS parameters). Work in progress in the area, including		filters, QoS parameters). Work in progress in the area, including
	NAS-Filter-Rule, RADIUS quality of service support, prepaid		NAS-Filter-Rule, RADIUS quality of service support, prepaid
	extensions etc. is performed. The relevant attributes may be reused		extensions etc. is performed. The relevant attributes may be reused
	for providing required functionality over the AAAH-HA interface.		for providing required functionality over the AAAH-HA interface.
	G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6		G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6
	skipping to change at page 22, line 9 ¶		skipping to change at page 23, line 9 ¶
	reauthorize the user, the Termination-Action attribute can be		reauthorize the user, the Termination-Action attribute can be
	included, with value 1, meaning the NAS should send a new RADIUS-		included, with value 1, meaning the NAS should send a new RADIUS-
	Request packet. Additional AVPs for dealing with pre-paid sessions		Request packet. Additional AVPs for dealing with pre-paid sessions
	(e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are		(e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are
	specified in RADIUS prepaid extension. Exchanging of application		specified in RADIUS prepaid extension. Exchanging of application
	specific authorization request/answer messages provides extension of		specific authorization request/answer messages provides extension of
	the authorization session (e.g., Authorize Only Access-Request sent		the authorization session (e.g., Authorize Only Access-Request sent
	by the HA (NAS) to the RADIUS server). Initiation of the re-		by the HA (NAS) to the RADIUS server). Initiation of the re-
	authorization by both sides could be supported. Both sides could		authorization by both sides could be supported. Both sides could
	initiate session termination - the RADIUS server by sending		initiate session termination - the RADIUS server by sending
	Disconnect message [14].		Disconnect message [15].
	7.3. Accounting		7.3. Accounting
	G3.1 The AAA-HA interface must support the transfer of accounting		G3.1 The AAA-HA interface must support the transfer of accounting
	records needed for service control and charging. These include (but		records needed for service control and charging. These include (but
	may not be limited to): time of binding cache entry creation and		may not be limited to): time of binding cache entry creation and
	deletion, octets sent and received by the MN in bi-directional		deletion, octets sent and received by the MN in bi-directional
	tunneling, etc.		tunneling, etc.
	The requirements for accounting over the AAAH-HA interface does not		The requirements for accounting over the AAAH-HA interface does not
	skipping to change at page 24, line 29 ¶		skipping to change at page 25, line 29 ¶
	MIP6-HA Address | M | P | | V | Y |		MIP6-HA Address | M | P | | V | Y |
	MIP6-HA-FQDN UTF8String | M | P | | V | Y |		MIP6-HA-FQDN UTF8String | M | P | | V | Y |
	MIP6-HL-Prefix OctetString| M | P | | V | Y |		MIP6-HL-Prefix OctetString| M | P | | V | Y |
	MIP6-HOA Address | M | P | | V | Y |		MIP6-HOA Address | M | P | | V | Y |
	MIP6-DNS-MO OctetString| M | P | | V | Y |		MIP6-DNS-MO OctetString| M | P | | V | Y |
	-------------------------------|----+-----+----+-----|----|		-------------------------------|----+-----+----+-----|----|
	Other than MIP6-HA and HOA-IPv6, the attributes in this specification		Other than MIP6-HA and HOA-IPv6, the attributes in this specification
	have no special translation requirements for Diameter to RADIUS or		have no special translation requirements for Diameter to RADIUS or
	RADIUS to Diameter gateways; they are copied as is, except for		RADIUS to Diameter gateways; they are copied as is, except for
	changes relating to headers, alignment, and padding. See also [15]		changes relating to headers, alignment, and padding. See also [16]
	Section 4.1 and [16] Section 9. MIP6-HA and HOA-IPv6 must be		Section 4.1 and [17] Section 9. MIP6-HA and HOA-IPv6 must be
	translated between their RADIUS representation of String to a		translated between their RADIUS representation of String to a
	Diameter Address format which requires that the AddressType field be		Diameter Address format which requires that the AddressType field be
	set to 2 for IP6 (IP version 6)		set to 2 for IP6 (IP version 6)
	What this specification says about the applicability of the		What this specification says about the applicability of the
	attributes for RADIUS Access-Request packets applies in Diameter to		attributes for RADIUS Access-Request packets applies in Diameter to
	AA-Request [16] or Diameter-EAP-Request [17]. What is said about		AA-Request [17] or Diameter-EAP-Request [18]. What is said about
	Access-Challenge applies in Diameter to AA-Answer [16] or Diameter-		Access-Challenge applies in Diameter to AA-Answer [17] or Diameter-
	EAP-Answer [17] with Result-Code AVP set to		EAP-Answer [18] with Result-Code AVP set to
	DIAMETER_MULTI_ROUND_AUTH.		DIAMETER_MULTI_ROUND_AUTH.
	What is said about Access-Accept applies in Diameter to AA-Answer or		What is said about Access-Accept applies in Diameter to AA-Answer or
	Diameter-EAP-Answer messages that indicate success. Similarly, what		Diameter-EAP-Answer messages that indicate success. Similarly, what
	is said about RADIUS Access-Reject packets applies in Diameter to AA-		is said about RADIUS Access-Reject packets applies in Diameter to AA-
	Answer or Diameter-EAP-Answer messages that indicate failure.		Answer or Diameter-EAP-Answer messages that indicate failure.
	What is said about Accounting-Request applies to Diameter Accounting-		What is said about Accounting-Request applies to Diameter Accounting-
	Request [16] as well.		Request [17] as well.
	10. Security Considerations		10. Security Considerations
	Assignment of these values to a user should be based on successful		Assignment of these values to a user should be based on successful
	authentication of the user at the NAS and/or at the HA. The RADIUS		authentication of the user at the NAS and/or at the HA. The RADIUS
	server should only assign these values to a user who is authorized		server should only assign these values to a user who is authorized
	for Mobile IPv6 service (this check could be performed with the		for Mobile IPv6 service (this check could be performed with the
	user's subscription profile in the Home Network).		user's subscription profile in the Home Network).
	The NAS and the HA to the RADIUS server transactions must be		The NAS and the HA to the RADIUS server transactions must be
	adequately secured. Otherwise there is a possibility that the user		adequately secured. Otherwise there is a possibility that the user
	may receive fraudulent values from a rogue RADIUS server potentially		may receive fraudulent values from a rogue RADIUS server potentially
	hijacking the user's Mobile IPv6 session.		hijacking the user's Mobile IPv6 session.
	These new attributes do not introduce additional security		These new attributes do not introduce additional security
	considerations besides the ones identified in [4].		considerations besides the ones identified in [5].
	11. IANA Considerations		11. IANA Considerations
	The following RADIUS attribute Type values MUST be assigned by IANA.		The following RADIUS attribute Type values MUST be assigned by IANA.
	MIP6-HA-TYPE		MIP6-HA-TYPE
	MIP6-HA-FQDN-TYPE		MIP6-HA-FQDN-TYPE
	MIP6-HL-PREFIX-TYPE		MIP6-HL-PREFIX-TYPE
	MIP6-HOA-TYPE		MIP6-HOA-TYPE
	MIP6-DNS-MO-TYPE		MIP6-DNS-MO-TYPE
			A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61)
	12. Acknowledgements		12. Acknowledgements
	We would like to thank the following individuals for their review and		We would like to thank the following individuals for their review and
	constructive comments during the development of this document:		constructive comments during the development of this document:
	Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev,		Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev,
	Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen.		Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for		[2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
	the Integrated Scenario",		Integrated Scenario",
	draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in		draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in
	progress), June 2006.		progress), February 2007.
	[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",		[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
	draft-ietf-mip6-bootstrapping-split-03 (work in progress),		draft-ietf-mip6-bootstrapping-split-04 (work in progress),
	October 2006.		December 2006.
	[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote		[4] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
	Authentication Dial In User Service (RADIUS)", RFC 2865,		RFC 2548, March 1999.
	June 2000.
			[5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
			Authentication Dial In User Service (RADIUS)", RFC 2865,
			June 2000.
	13.2. Informative References		13.2. Informative References
	[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping		[7] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
	Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in		Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
	progress), May 2006.		progress), May 2006.
	[7] Manner, J. and M. Kojo, "Mobility Related Terminology",		[8] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.		RFC 3753, June 2004.
	[8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with		[9] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
	IKEv2 and the revised IPsec Architecture",		IKEv2 and the revised IPsec Architecture",
	draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006.		draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
			December 2006.
	[9] Mockapetris, P., "Domain names - implementation and		[10] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[10] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
	In User Service) Support For Extensible Authentication Protocol		In User Service) Support For Extensible Authentication Protocol
	(EAP)", RFC 3579, September 2003.		(EAP)", RFC 3579, September 2003.
	[11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[12] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter",		[13] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter",
	draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress),		draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress),
	October 2005.		October 2005.
	[13] Giaretta, G., "AAA Goals for Mobile IPv6",		[14] Giaretta, G., "AAA Goals for Mobile IPv6",
	draft-ietf-mip6-aaa-ha-goals-03 (work in progress),		draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
	September 2006.		September 2006.
	[14] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,		[15] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
	"Dynamic Authorization Extensions to Remote Authentication Dial		"Dynamic Authorization Extensions to Remote Authentication Dial
	In User Service (RADIUS)", RFC 3576, July 2003.		In User Service (RADIUS)", RFC 3576, July 2003.
	[15] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,		[16] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, September 2003.		"Diameter Base Protocol", RFC 3588, September 2003.
	[16] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter		[17] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
	Network Access Server Application", RFC 4005, August 2005.		Network Access Server Application", RFC 4005, August 2005.
	[17] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[18] 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.
	[18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
	[19] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to		[20] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
	Protect Mobile IPv6 Signaling Between Mobile Nodes and Home		Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
	Agents", RFC 3776, June 2004.		Agents", RFC 3776, June 2004.
	[20] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic		[21] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
	Updates in the Domain Name System (DNS UPDATE)", RFC 2136,		Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
	April 1997.		April 1997.
	Authors' Addresses		Authors' Addresses
	Kuntal Chowdhury		Kuntal Chowdhury
	Starent Networks		Starent Networks
	30 International Place		30 International Place
	Tewksbury, MA 01876		Tewksbury, MA 01876
	US		US
	skipping to change at page 31, line 7 ¶		skipping to change at page 32, line 7 ¶
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 71 change blocks.
	130 lines changed or deleted		182 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/