< draft-chowdhury-mip6-radius-01.txt		draft-chowdhury-mip6-radius-02.txt >
	Network Working Group K. Chowdhury		MIP6 K. Chowdhury
	Internet-Draft Starent Networks		Internet-Draft Starent Networks
	Expires: September 7, 2006 A. Lior		Expires: December 25, 2006 A. Lior
	Bridgewater Systems		Bridgewater Systems
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	March 6, 2006		June 23, 2006
	RADIUS Mobile IPv6 Support		RADIUS Mobile IPv6 Support
	draft-chowdhury-mip6-radius-01.txt		draft-chowdhury-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 September 7, 2006.		This Internet-Draft will expire on December 25, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	A Mobile IPv6 node requires a home agent address, a home address, and		A Mobile IPv6 node requires a home agent address, a home address, and
	IPsec security association with its home agent before it can start		an IPsec security association with its home agent before it can start
	utilizing Mobile IPv6 service. RFC 3775 requires that some or all of		utilizing Mobile IPv6 service. RFC 3775 requires that some or all of
	these parameters are statically configured. Ongoing work aims to		these parameters are statically configured. Ongoing work aims to
	make this information dynamically available to the mobile node. An		make this information dynamically available to the mobile node. An
	important aspect of the Mobile IPv6 bootstrapping solution is to		important aspect of the Mobile IPv6 bootstrapping solution is to
	support interworking with existing authentication, authorization and		support interworking with the existing authentication, authorization
	accounting infrastructure. This document defines the new attributes		and accounting infrastructure. This document defines new attributes
	to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure.		that facilitate Mobile IPv6 bootstrapping via a RADIUS
	This information exchange may take place as part of the initial		infrastructure. This information exchange may take place as part of
	network access authentication procedure or as part of a separate		the initial network access authentication procedure or as part of a
	protocol exchange between the mobile node, the home agent and the AAA		separate protocol exchange between the mobile node, the home agent
	infrastructure.		and the AAA infrastructure.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	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. Home Agent Address Attribute . . . . . . . . . . . . . . . 9		4.1. Home Agent Address Attribute . . . . . . . . . . . . . . . 9
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	12.2. Informative References . . . . . . . . . . . . . . . . . . 26		12.2. Informative References . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . . . . 29
	1. Introduction		1. Introduction
	Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform		The Mobile IPv6 specification [5] requires a Mobile Node (MN) to
	registration with a Home Agent with information about its current		perform registration with a Home Agent with information about its
	point of attachment (Care-of Address). The Home Agent creates and		current point of attachment (Care-of Address). The Home Agent
	maintains binding between the MN's Home Address and the MN's Care-of		creates and maintains a binding between the MN's Home Address and the
	Address.		MN's Care-of Address.
	In order to register with a Home Agent, the MN needs to know some		In order to register with a Home Agent, the MN needs to know some
	information such as, the Home Link prefix, the Home Agent Address,		information such as the Home Link prefix, the Home Agent Address, the
	the Home Address, the Home Link prefix Length and security related		Home Address, the Home Link prefix Length and security related
	information in order to secure the Binding Update.		information in order to secure the 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
	drawbacks. It increases provisioning and network maintenance burden		drawbacks. It increases provisioning and network maintenance burden
	for the operator. Moreover, static provisioning does not allow load		for the operator. Moreover, static provisioning does not allow load
	balancing, failover, opportunistic home link assignment etc. For		balancing, failover, opportunistic home link assignment etc. For
	example, the user may be accessing the network from a location that		example, the user may be accessing the network from a location that
	may be geographically far away from the preconfigured home link; the		may be geographically far away from the preconfigured home link; the
	administrative burden to configure the MN's with the respective		administrative burden to configure the MN's with the respective
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	service are authorized by different entities.		service are authorized by different entities.
	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 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		[6]). 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 home agent to AAA server and the network access		offer support for the home agent to AAA server and the network access
	server to AAA server communication.		server 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
	the network access authentication procedure. Figure 1 shows the		the network access authentication procedure. Figure 1 shows the
	participating entity.		participating entities.
	+---------------------------+ +-----------------+		+---------------------------+ +-----------------+
	|Access Service Provider | |ASA/MSA/(/MSP) |		|Access Service Provider | |ASA/MSA/(/MSP) |
	|(Mobility Service Provider)| | |		|(Mobility Service Provider)| | |
	| | | +-------+ |		| | | +-------+ |
	| +-------+ | | |Remote | |		| +-------+ | | |Remote | |
	| |Local | RADIUS | | |RADIUS | |		| | | RADIUS | | |RADIUS | |
	| |RADIUS |-------------------------|Server | |		| |RADIUS |-------------------------|Server | |
	| |Proxy | | | +-------+ |		| |Proxy | | | +-------+ |
	| +-------+ | | ^ |		| +-------+ | | ^ |
	| ^ ^ | | |RADIUS |		| ^ ^ | | |RADIUS |
	| | | | | | |		| | | | | | |
	| | | | | v |		| | | | | v |
	| |RADIUS | | +-------+ |		| |RADIUS | | +-------+ |
	| | | +-------+ | | |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 | +-----------+ +-------+ |
	+---------------------------+		+---------------------------+
	Figure 1: Mobile IPv6 Service Access in the Integrated Scenario		Figure 1: Mobile IPv6 Service Access in the Integrated Scenario
	In the typical Mobile IPv6 access scenario as shown above, the MN		In the typical Mobile IPv6 access scenario as shown above, the MN
	attaches in a Access Service Provider's network. During this network		attaches in a Access Service Provider's network. During this network
	attachment procedure, the NAS/RADIUS client interacts with the mobile		attachment procedure, the NAS/RADIUS client interacts with the mobile
	node. As shown in Figure 1, the authentication and authorization		node. As shown in Figure 1, the authentication and authorization
	happens via a RADIUS infrastructure.		happens via a RADIUS infrastructure.
	At the time of authorizing the user for IPv6 access, the RADIUS		At the time of authorizing the user for IPv6 access, the RADIUS
	server in the MSA detects that the user is authorized for Mobile IPv6		server in the MSA detects that the user is authorized to use the
	access. Based on the MSA's policy, the RADIUS server may allocate		Mobile IPv6 service, too. Based on the MSA's policy, the RADIUS
	several parameters to the MN for use during the subsequent Mobile		server may allocate several parameters to the MN for use during the
	IPv6 protocol interaction with the home agent.		subsequent Mobile IPv6 protocol interaction with the home agent.
	Depending on the details of the solution interaction with the DHCPv6		Depending on the details of the solution, an interaction with the
	server may be required, as described in [2].		DHCPv6 server may be required, as described in [2].
	3.2. Split Scenario		3.2. Split Scenario
	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 mobile node. Two variations can be		Provider when desired by the mobile node. Two variations can be
	considered:		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 32 ¶		skipping to change at page 8, line 32 ¶
	| | 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 mobile node and the home agent/RADIUS client using IKEv2 (see [3]		the mobile node and the home agent/RADIUS client using IKEv2 (see [3]
	and [8]). The home agent / RADIUS Client interacts with the RADIUS		and [8]). The home agent (i.e., RADIUS client) interacts with the
	infrastructure to perform authentication, authorization, accounting		RADIUS infrastructure in order to perform authentication,
	and parameter bootstrapping. The exchange is triggered by the home		authorization, accounting and parameter bootstrapping. The AAA
	agent and an interaction with the RADIUS infrastructure is initiated.		exchange is triggered by the home agent. When the protocol exchange
	When the protocol exchange is completed then the home agent needs to		is completed then the home agent possesses the Mobile IPv6 specific
	possess the Mobile IPv6 specific parameters (see [6]).		parameters (see [6]).
	Additionally, the mobile node might instruct the RADIUS server (via		Additionally, the mobile node may instruct the RADIUS server (via the
	the home agent) to perform a dynamic DNS update.		home agent) to perform a dynamic DNS update.
	4. RADIUS Attribute Overview		4. RADIUS Attribute Overview
	4.1. Home Agent Address Attribute		4.1. Home Agent Address Attribute
	The RADIUS server may decide to assign a Home Agent to the MN that is		The RADIUS server may decide to assign a Home Agent to the MN that is
	in close proximity to the point of attachment (e.g., determined by		in close proximity to the point of attachment (e.g., determined by
	the NAS-ID). There may be other reasons for dynamically assigning		the NAS-ID). There may be other reasons for dynamically assigning
	Home Agents to the MN, for example to share the traffic load. The		Home Agents to the MN, for example to share the traffic load. The
	attribute also contains the prefix length so that the MN can easily		attribute also contains the prefix length so that the MN can infer
	infer the Home Link prefix from the Home Agent address.		the Home Link prefix from the Home Agent address.
	4.2. Home Agent FQDN Attribute		4.2. Home Agent FQDN Attribute
	The RADIUS server may assign an FQDN of the home address to the MN.		The RADIUS server may assign an home agent address FQDN. The mobile
	The mobile node can perform DNS query with the FQDN to derive the		node can perform a DNS query with the FQDN to derive the home agent
	home agent address.		address.
	4.3. Home Link Prefix Attribute		4.3. Home Link 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).
	discover other information for Mobile IPv6 registration.
	4.4. Home Address Attribute		4.4. Home Address Attribute
	The RADIUS server may assign a Home Address to the MN. This allows		The RADIUS server may assign a Home Address to the MN. This allows
	the network operator to support mobile devices that are not		the network operator to support mobile devices that are not
	configured with static addresses. The attribute also contains the		configured with static addresses. The attribute also contains the
	prefix length so that the MN can easily infer the Home Link prefix		prefix length so that the MN can easily infer the Home Link prefix
	from the Home Agent address.		from the Home Agent address.
	4.5. DNS Update Mobility Option Attribute		4.5. DNS Update Mobility Option Attribute
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	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 DNS Update Mobility Option attribute.		the response MUST include the DNS Update Mobility Option attribute.
	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 the Access-Accept and the
			Accounting-Request.
	5.1. Home Agent Address Attribute		5.1. Home Agent Address Attribute
	This attribute is sent by the RADIUS server to the NAS in an Access-		This attribute is sent by the RADIUS server to the NAS in an Access-
	Accept message. The attribute carries the assigned Home Agent		Accept message. The attribute carries the assigned Home Agent
	address.		address.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 25 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FQDN of the assigned home agent ...		| FQDN of the assigned home agent ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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.
	Reserved:		Reserved:
	Reserved for future use. All bits set to 0.		Reserved for future use. All bits set to 0.
	FQDN of the assigned home agent:		FQDN of the assigned home agent:
	The data field MUST contain a FQDN as described in [9].		The data field MUST contain a FQDN as described in [9].
	5.3. Home Link Prefix Attribute		5.3. Home Link Prefix Attribute
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 10 ¶
	| |		| |
	| Home Link Prefix |		| Home Link Prefix |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		Type:
	ASSIGNED-HL-TYPE to be defined by IANA.		ASSIGNED-HL-TYPE to be defined by IANA.
	Length:		Length:
	>= 4 octets + the minimum length of a prefix.		Variable
	Reserved:		Reserved:
	Reserved for future use. All bits set to 0.		Reserved for future use. All bits set to 0.
	Home Link Prefix:		Home Link Prefix:
	Home Link prefix (upper order bits) of the assigned Home Link		Home Link prefix (upper order bits) of the assigned Home Link
	where the MN should send binding update.		where the MN should send binding update.
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 35 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved-2 | FQDN ...		|R| Reserved-2 | FQDN ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		Type:
	DNS-UPDATE-TYPE to be defined by IANA.		DNS-UPDATE-TYPE to be defined by IANA.
	Length:		Length:
	Variable length.		Variable
	Reserved-1:		Reserved-1:
	Reserved for future use. All bits set to 0.		Reserved for future use. All bits set to 0.
	Status:		Status:
	This 8 bit unsigned integer field indicates the result of the		This 8 bit unsigned integer field indicates the result of the
	dynamic DNS update procedure. This field MUST be set to 0 and		dynamic DNS update procedure. This field MUST be set to 0 and
	ignored by the RADIUS server when the DNS Update Mobility		ignored by the RADIUS server when the DNS Update Mobility
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	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.
	The NAS encapsulates/decapsulates EAP packets into/from RADIUS		The NAS encapsulates/decapsulates EAP packets into/from RADIUS
	messages until an Access-Response (either an Access-Accept or an		messages until an Access-Response (either an Access-Accept or an
	Access/Reject packet is received by the NAS). This concludes the		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 Home Agent Address		Depending on the RADIUS server configuration, the Home Agent Address
	attribute or the the Home Agent FQDN attribute may be appended to the		attribute or the Home Agent FQDN attribute may be appended to the
	Access-Accept message. In the latter case the MN needs to perform a		Access-Accept message. In the latter case the MN needs to perform a
	DNS query in order to discover the Home Agent address.		DNS query in order to discover the Home Agent address.
	The Home Agent Address or Home Agent FQDN attribute is appended to		The Home Agent Address or Home Agent FQDN attribute is appended to
	the access accept in case the home RADIUS server knows or has		the access accept in case the home RADIUS server knows or has
	allocated a HA to the access request (this is assumed in this		allocated a HA to the access request (this is assumed in this
	scenario).		scenario).
	In step (2) the MN sends a DHCPv6 Information Request message to		In step (2) the MN sends a DHCPv6 Information Request message to
	all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code		all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 34 ¶
	1, the message is a request to discover home network information that		1, the message is a request to discover home network information that
	pertains to the given realm, i.e., the user's home domain (identified		pertains to the given realm, i.e., the user's home domain (identified
	by the NAI of the MN). The OPTION_CLIENTID is set by the MN to		by the NAI of the MN). The OPTION_CLIENTID is set by the MN to
	identify itself to the DHCP server.		identify itself to the DHCP server.
	In step (3) the DHCP relay agent forwards this request to the DHCP		In step (3) the DHCP relay agent forwards this request to the DHCP
	server. The OPTION_MIP6-RELAY-Option is included in this forwarded		server. The OPTION_MIP6-RELAY-Option is included in this forwarded
	message. This option carries the RADIUS Home Agent Address Attribute		message. This option carries the RADIUS Home Agent Address Attribute
	from the access accept message.		from the access accept message.
	In step (4), the DHCP server identifies the client (by DUID) and		In step (4), the DHCP server identifies the client and finds out that
	finds out that it requests home agent information in the MSP (by the		it requests home agent information in the MSP (by the Home Network
	Home Network Identifier Option = 1). The DHCP server extracts the		Identifier Option = 1). The DHCP server extracts the home agent
	home agent address from OPTION_MIP6-RELAY-Option and places it into		address from OPTION_MIP6-RELAY-Option and places it into Home Network
	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 Mobile		In step (5), the Relay Agent forwards the Reply Message to the Mobile
	Node. On reception of this message, the home agent address or the		Node. On reception of this message, the home agent address or the
	FQDN of the home agent is available at the MN.		FQDN of the home agent is available at the MN.
	6.1.2. Home Agent allocation in the ASP (visited network)		6.1.2. Home Agent 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 Home		Network Identifier Option is set to zero, indicating that a Home
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 26 ¶
	authentication procedure and the MIPv6 bootstrapping procedure.		authentication procedure and the MIPv6 bootstrapping procedure.
	In order to learn the IP address of the home agent, the MN either		In order to learn the IP address of the home agent, the MN either
	performs a DNS lookup of the Home Agent Name or a DNS lookup by		performs a DNS lookup of the Home Agent Name or a DNS lookup by
	service name. In the first case, the MN is preconfigured with the		service name. In the first case, the MN is preconfigured with the
	FQDN of the HA, and thus sends a DNS request, where QNAME = name of		FQDN of the HA, and thus sends a DNS request, where QNAME = name of
	HA, QTYPE='AAAA' (request for IPv6 address of HA). A DNS reply		HA, QTYPE='AAAA' (request for IPv6 address of HA). A DNS reply
	message is returned by the DNS server with the HA address.		message is returned by the DNS server with the HA address.
	The MN then runs IKEv2 with the HA in order to set up IPsec SAs		The MN then runs IKEv2 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, the MN is authenticated and authorized for the IPv6		within IKEv2, the MN is authenticated and authorized for the IPv6
	mobility service and is also assigned a home address.		mobility service and is also assigned a home address.
	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 the Diameter
	protocol in [10]. The described mechanism ensureas that common		protocol in [10]. The described mechanism ensures that common keying
	keying material will be available at the MN and HA after successful		material will be available at the MN and the 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 18 ¶		skipping to change at page 20, line 18 ¶
	AAA-Goals document [11].		AAA-Goals document [11].
	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 in RADIUS (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 the Network
	Identifier (NAI) to identify the mobile node. The User-Name		Access Identifier (NAI) to identify the mobile node. The User-Name
	attribute can be used for the purpose to carry the NAI.		attribute can be 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 in order to
	IPv6 service authorization for the mobile node. Any node		verify Mobile IPv6 service authorization for the mobile node. Any
	implementing RADIUS functionality can possibly initiate a request		node implementing RADIUS functionality can possibly initiate a
	message. In combination with the ability of the RADIUS protocol to		request message. In combination with the ability of the RADIUS
	carry EAP messages, our solution will enable an HA to query a RADIUS		protocol to carry EAP messages, the mechanisms described in this
	server and verify MIPv6 authorization for the MN.		document enable an HA to query a RADIUS 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
	session by the AAAH server, e.g., authorization lifetime, extension		session by the AAAH server, e.g., authorization lifetime, extension
	skipping to change at page 23, line 7 ¶		skipping to change at page 23, line 7 ¶
	0-1 0-1 0 0 DNS Update Mobility Option		0-1 0-1 0 0 DNS Update Mobility Option
	Attribute		Attribute
	The following table defines the meaning of the above table entries.		The following table defines the meaning of the above table entries.
	0 This attribute MUST NOT be present.		0 This attribute MUST NOT be present.
	0-1 Zero or one instance of this attribute MAY be present.		0-1 Zero or one instance of this attribute MAY be present.
	9. Security Considerations		9. Security Considerations
	Assignment of these values to a user should be based on successful		Assignment of MIPv6 specific parameters has to be based on a protocol
	authentication of the user at the NAS and/or at the home agent. The		run between the participating parties with a successful outcome
	RADIUS server should only assign these values to a user who is		(i.e., successful authentication and authorization). The RADIUS
	authorized for Mobile IPv6 service (this check could be performed		server should only assign MIPv6 specific parameters to an end host
	with the user's subscription profile in the Home Network).		that is authorized for Mobile IPv6 service. This check could be
			performed with the user's subscription profile in the Home Network.
	The NAS and the home agent to the RADIUS server transactions must be		The NAS and the home agent 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 [4].
	10. IANA Considerations		10. IANA Considerations
	The following RADIUS attribute Type values MUST be assigned by IANA.		The following RADIUS attribute Type values MUST be assigned by IANA.
	ASSIGNED-HA-ADDR-TYPE		o ASSIGNED-HA-ADDR-TYPE
	ASSIGNED-HA-FQDN-TYPE		o ASSIGNED-HA-FQDN-TYPE
	ASSIGNED-HL-TYPE		o ASSIGNED-HL-TYPE
	ASSIGNED-HOA-TYPE		o ASSIGNED-HOA-TYPE
	DNS-UPDATE-TYPE		o DNS-UPDATE-TYPE
	11. Acknowledgements		11. 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.		Andreas Pashalidis, Rafa Marin Lopez.
	12. References		12. References
	12.1. Normative References		12.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 via DHCPv6 for
	the Integrated Scenario",		the Integrated Scenario",
	draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in		draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
	progress), October 2005.		progress), June 2006.
	[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",		[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
	draft-ietf-mip6-bootstrapping-split-01 (work in progress),		draft-ietf-mip6-bootstrapping-split-02 (work in progress),
	October 2005.		March 2006.
	[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote		[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865,		Authentication Dial In User Service (RADIUS)", RFC 2865,
	June 2000.		June 2000.
	12.2. Informative References		12.2. Informative References
	[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[5] 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		[6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
	Mobile IPv6", draft-ietf-mip6-bootstrap-ps-04 (work in		Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
	progress), February 2006.		progress), May 2006.
	[7] Manner, J. and M. Kojo, "Mobility Related Terminology",		[7] 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		[8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
	IKEv2 and the revised IPsec", draft-ietf-mip6-ikev2-ipsec-04		IKEv2 and the revised IPsec Architecture",
	(work in progress), October 2005.		draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006.
	[9] Mockapetris, P., "Domain names - implementation and		[9] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[10] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter",		[10] Korhonen, J., "Diameter MIPv6 Bootstrapping for the Integrated
	draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress),		Scenario", draft-ietf-dime-mip6-integrated-00 (work in
	October 2005.		progress), June 2006.
	[11] Giaretta, G., "Goals for AAA-HA interface",		[11] Giaretta, G., "Goals for AAA-HA interface",
	draft-ietf-mip6-aaa-ha-goals-01 (work in progress),		draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
	January 2006.		January 2006.
	[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[12] 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.
	[13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to		[13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
End of changes. 44 change blocks.
	91 lines changed or deleted		93 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/