< draft-ietf-mext-aaa-ha-goals-00.txt		draft-ietf-mext-aaa-ha-goals-01.txt >
	MEXT Working Group G. Giaretta		MEXT Working Group G. Giaretta
	Internet-Draft Qualcomm		Internet-Draft Qualcomm
	Expires: June 29, 2008 I. Guardini		Intended status: Informational I. Guardini
	E. Demaria		Expires: November 3, 2008 E. Demaria
	Telecom Italia		Telecom Italia
	J. Bournelle		J. Bournelle
	Orange Labs		Orange Labs
	R. Lopez		R. Lopez
	Univ. of Murcia		Univ. of Murcia
	December 27, 2007		May 2, 2008
	AAA Goals for Mobile IPv6		AAA Goals for Mobile IPv6
	draft-ietf-mext-aaa-ha-goals-00		draft-ietf-mext-aaa-ha-goals-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 29, 2008.		This Internet-Draft will expire on November 3, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	In commercial and enterprise deployments Mobile IPv6 can be a service		In commercial and enterprise deployments Mobile IPv6 can be a service
	offered by a Mobility Services Provider (MSP). In this case all		offered by a Mobility Services Provider (MSP). In this case all
	protocol operations may need to be explicitly authorized and traced,		protocol operations may need to be explicitly authorized and traced,
	requiring the interaction between Mobile IPv6 and the AAA		requiring the interaction between Mobile IPv6 and the AAA
	infrastructure. Integrating the AAA infrastructure (e.g. NAS and		infrastructure. Integrating the AAA infrastructure (e.g. NAS and
	AAA server) offers also a solution component for Mobile IPv6		AAA server) offers also a solution component for Mobile IPv6
	bootstrapping. This document describes various scenarios where a AAA		bootstrapping. This document describes various scenarios where a AAA
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 22 ¶
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4		4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4
	4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5		4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5
	5. Goals for AAA-HA interface . . . . . . . . . . . . . . . . . . 6		5. Goals for AAA-HA interface . . . . . . . . . . . . . . . . . . 6
	5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6		5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Service Authorization . . . . . . . . . . . . . . . . . . 6		5.2. Service Authorization . . . . . . . . . . . . . . . . . . 6
	5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7		5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8		5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8
	5.5. Provisioning of Configuration Parameters . . . . . . . . . 8		5.5. Provisioning of Configuration Parameters . . . . . . . . . 8
	6. Goals for the AAA-NAS interface . . . . . . . . . . . . . . . 9		6. Goals for the AAA-NAS interface . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Introduction		1. Introduction
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	provisioned with a set of configuration parameters, namely the Home		provisioned with a set of configuration parameters, namely the Home
	Address and the Home Agent Address, in order to accomplish a home		Address and the Home Agent Address, in order to accomplish a home
	registration. Moreover, MNs and Home Agents (HAs) must share the		registration. Moreover, MNs and Home Agents (HAs) must share the
	cryptographic material needed in order to setup IPsec security		cryptographic material needed in order to setup IPsec security
	associations to protect Mobile IPv6 signaling (e.g. shared keys or		associations to protect Mobile IPv6 signaling (e.g. shared keys or
	certificates). This is referred as the bootstrapping problem: as		certificates). This is referred as the bootstrapping problem: as
	described in [2], the AAA infrastructure can be used as the central		described in [2], the AAA infrastructure can be used as the central
	element to enable dynamic Mobile IPv6 bootstrapping. In this case		element to enable dynamic Mobile IPv6 bootstrapping. In this case
	the AAA infrastructure can be exploited to offload the end host's		the AAA infrastructure can be exploited to offload the end host's
	authentication to the AAA server as well as to deliver the necessary		authentication to the AAA server as well as to deliver the necessary
	configuration parameters to the visited network.		configuration parameters to the visited network (e.g. Home Agent
			address as specified in [4]).
	Moreover, in case Mobile IPv6 is a service offered by a Mobility		Moreover, in case Mobile IPv6 is a service offered by a Mobility
	Service Provider (MSP), all protocol operations (e.g., home		Service Provider (MSP), all protocol operations (e.g., home
	registrations) may need to be explicitly authorized and monitored		registrations) may need to be explicitly authorized and monitored
	(e.g., for accounting purposes). This can be accomplished relying on		(e.g., for accounting purposes). This can be accomplished relying on
	the AAA infrastructure of the MSA that stores user profiles and		the AAA infrastructure of the MSA that stores user profiles and
	credentials.		credentials.
	4. Bootstrapping Scenarios		4. Bootstrapping Scenarios
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 22 ¶
	Then the Mobile Node performs an IKEv2 [8] exchange with the HA to		Then the Mobile Node performs an IKEv2 [8] exchange with the HA to
	setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure		setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure
	its Home Address (HoA). Mutual authentication for IKEv2 between		its Home Address (HoA). Mutual authentication for IKEv2 between
	Mobile Node and Home Agent can be done with or without use of		Mobile Node and Home Agent can be done with or without use of
	Extensible Authentication Protocol (EAP).		Extensible Authentication Protocol (EAP).
	If EAP is used for authentication, the operator can choose any		If EAP is used for authentication, the operator can choose any
	available EAP methods. Use of EAP with the AAA infrastructure allows		available EAP methods. Use of EAP with the AAA infrastructure allows
	the HA for not necessarily maintaining authentication credentials for		the HA for not necessarily maintaining authentication credentials for
	each Mobile Node by itself. It also allows roaming in terms of		each Mobile Node by itself, checking the validity of the credentials
			with the AAA infrastructure. It also allows roaming in terms of
	Mobile IPv6 service where MSP and MSA belong to different		Mobile IPv6 service where MSP and MSA belong to different
	administrative domains.		administrative domains. In this case the HA in the MSP can check the
			vailidity of the credentials provided by the MN with the AAA
			infrastructure of MSA, receiving the relevant authorization
			information.
	The Mobile Node may also want to update its FQDN in the DNS with the		The Mobile Node may also want to update its FQDN in the DNS with the
	newly allocated Home Address. [3] recommends that the HA performs the		newly allocated Home Address. [3] recommends that the HA performs the
	DNS entry update on behalf of the Mobile Node. For that purpose, the		DNS entry update on behalf of the Mobile Node. For that purpose, the
	Mobile Node indicates its FDQN in the IKEv2 exchange (IDi field in		Mobile Node indicates its FDQN in the IKEv2 exchange (IDi field in
	IKE_AUTH) and adds a DNS Update Option in the Binding Update message		IKE_AUTH) and adds a DNS Update Option in the Binding Update message
	sent to the HA.		sent to the HA.
	When the Mobile Node uses a Home Agent belonging to a different		When the Mobile Node uses a Home Agent belonging to a different
	administrative domain (MSP != MSA), the local HA may not share a		administrative domain (MSP != MSA), the local HA may not share a
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 50 ¶
	suggests that the home AAA server is responsible for the update.		suggests that the home AAA server is responsible for the update.
	Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.		Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
	4.2. Integrated Scenario		4.2. Integrated Scenario
	In the integrated scenario [4], the assumption is that the Access		In the integrated scenario [4], the assumption is that the Access
	Service Authorizer (ASA) is same as the Mobility Service Authorizer		Service Authorizer (ASA) is same as the Mobility Service Authorizer
	(MSA).		(MSA).
	The Home Agent can the assigned either in the Access Service		The Home Agent can the assigned either in the Access Service
	Provider's network or in the seprate network. In the former case,		Provider's network or in the separate network. In the former case,
	the MSP is the same entity as the ASP, whereas in the latter case MSP		the MSP is the same entity as the ASP, whereas in the latter case MSP
	and ASP are different entities.		and ASP are different entities.
	In this scenario, Mobile Node discovers the Home Agent Address using		In this scenario, Mobile Node discovers the Home Agent Address using
	DHCPv6. If the user is authorized for Mobile IPv6 service, during		DHCPv6. If the user is authorized for Mobile IPv6 service, during
	the network access authentication the AAAH sends the information		the network access authentication the AAAH sends the information
	about the assigned home agent to the Network Access Server (NAS)		about the assigned Home Agent to the Network Access Server (NAS)
	where the Mobile Node is currently attached. To request home agent		where the Mobile Node is currently attached. To request Home Agent
	data, the Mobile Node sends a DHCPv6 Information Request to the		data, the Mobile Node sends a DHCPv6 Information Request to the
	All_DHCP_Relay_Agents_and_Servers multicast address. With this		All_DHCP_Relay_Agents_and_Servers multicast address. With this
	request, the Mobile Node can specify if it wants a home agent		request, the Mobile Node can specify if it wants a Home Agent
	provided by the visited domain (ASP/MSP) or by the home domain (ASA/		provided by the visited domain (ASP/MSP) or by the home domain (ASA/
	MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS		MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS
	receives the DHCPv6 Information Request then it sends home agent		receives the DHCPv6 Information Request then it sends Home Agent
	information received from AAAH in a new DHC Relay Agent Option as		information received from AAAH in a new DHC Relay Agent Option as
	defined in [4].		defined in [4].
	In case the Mobile Node cannot acquire home agent information via		In case the Mobile Node cannot acquire Home Agent information via
	DHCPv6, it can try the default mechanism based on DNS described in		DHCPv6, it can try the default mechanism based on DNS described in
	[3]. After the Mobile Node has acquired the home agent information,		[3]. After the Mobile Node has acquired the Home Agent information,
	the mechanism used to bootstrap the HoA, IPsec Security Association,		the mechanism used to bootstrap the HoA, IPsec Security Association,
	and Authentication and Authorization with the MSA is the same		and Authentication and Authorization with the MSA is the same
	described in the bootstrapping solution for split scenario [3].		described in the bootstrapping solution for split scenario [3].
	5. Goals for AAA-HA interface		5. Goals for AAA-HA interface
	Section 4 raises the need to define extensions for the AAA protocol		Section 4 raises the need to define extensions for the AAA protocol
	used between the AAA server of the MSA and the HA. The following		used between the AAA server of the MSA and the HA. The following
	sections list the goals for such an interface. This communication is		sections list the goals for such an interface. This communication is
	needed for both split and integrated scenario.		needed for both split and integrated scenario.
	5.1. General goals		5.1. General goals
	G1.1 The AAAH server and the HA MUST be able to authenticate each		G1.1 The communication between the AAAH server and the HA MUST reuse
	other (mutual authentication) in order to prevent the installation		existing AAA security mechanisms with regard to authentication,
	of unauthorized state on the HA. In some deployment scenarios, it		replay, integrity, and confidentiality protection. These
	may not be feasible for HA and AAA server to mutually authenticate		communication security mechanisms prevent a number of classical
	each other. In such a case, several AAA intermediate proxies		threats, including the alteration of exchanged data (e.g., Mobile
	could forward MIP6 bootstrapping information between HA and AAA.		IPv6 configuration parameters) and the installation of
	Thus, to prevent the installation of unauthorized state on the HA,		unauthorized state.
	the path between HA and AAAH should be secure.
	G1.2 The AAA-HA interface MUST provide integrity protection in order
	to prevent any alteration of exchanged data (e.g., Mobile IPv6
	configuration parameters).
	G1.3 The AAA-HA interface MUST provide replay protection.
	5.2. Service Authorization		5.2. Service Authorization
	G2.1 The AAA-HA interface MUST allow the use of Network Access		G2.1 The AAA-HA interface MUST allow the use of Network Access
	Identifier (NAI) to identify the user.		Identifier (NAI) to identify the user.
	G2.2 The HA MUST be able to query the AAAH server to verify Mobile		G2.2 The HA MUST be able to query the AAAH server to verify Mobile
	IPv6 service authorization for the mobile node.		IPv6 service authorization for the mobile node.
	G2.3 The AAAH server MAY assign explicit operational limitations and		G2.3 The AAAH server MAY assign explicit operational limitations and
	authorization restrictions on the HA (e.g., packet filters, QoS		authorization restrictions on the HA (e.g., packet filters, QoS
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	G2.4 The AAAH server MUST be able to send an authorization lifetime		G2.4 The AAAH server MUST be able to send an authorization lifetime
	to the HA to limit Mobile IPv6 session duration for the MN.		to the HA to limit Mobile IPv6 session duration for the MN.
	G2.5 The HA MUST be able to request to the AAAH server an extension		G2.5 The HA MUST be able to request to the AAAH server an extension
	of the authorization lifetime granted to the MN.		of the authorization lifetime granted to the MN.
	G2.6 The AAAH server MUST be able to force the HA to terminate an		G2.6 The AAAH server MUST be able to force the HA to terminate an
	active Mobile IPv6 session for authorization policy reasons (e.g.,		active Mobile IPv6 session for authorization policy reasons (e.g.,
	credit exhaustion).		credit exhaustion).
	G2.7 The HA MUST be able to indicate the IPv6 HoA that will be		G2.7 The HA MUST be able to indicate to the AAAH the IPv6 HoA that
	assigned to the MN.		will be assigned to the MN.
	G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6		G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6
	HoA.		HoA and MUST indicate that to the HA.
	G2.9 The AAAH server MUST be able to indicate to the HA whether		G2.9 The AAAH server MUST be able to indicate to the HA whether
	return routability test (HoT, HoTi) shall be permitted or not via		return routability test (HoT, HoTi) shall be permitted or not via
	the HA for a given MN.		the HA for a given MN.
	G2.10 The AAAH server MUST be able to authorize the MN for Dual		G2.10 The AAAH server MUST be able to support different levels of
	Stack operation [9].		Mobile IPv6 authorization. For example, the AAAH server may
			authorize the MN to use of MIPv6 (as defined in [1]) or may
			authorize the MN to utilize an IPv4 HoA assigned for Dual Stack
			MIPv6 [9].
	G2.11 The AAAH server MUST be able to indicate to the HA whether the		G2.11 The AAAH server MUST be able to indicate to the HA whether the
	bearer traffic for the MN needs to receive IPsec ESP protection.		bearer traffic for the MN needs to receive IPsec ESP protection.
	G2.12 The HA MUST be able to authenticate the MN through the AAAH in		G2.12 The HA MUST be able to authenticate the MN through the AAAH in
	case a pre-share key is used in IKEv2 for user authentication.		case a pre-share key is used in IKEv2 for user authentication.
	The exact procedure is part of the solution space.		The exact procedure is part of the solution space.
	5.3. Accounting		5.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		records needed for service control and charging. These include
	(but may not be limited to): time of binding cache entry creation		(but may not be limited to): time of binding cache entry creation
	and deletion, octets sent and received by the mobile node in bi-		and deletion, octets sent and received by the mobile node in bi-
	directional tunneling, etc.		directional tunneling, etc.
	5.4. Mobile Node Authentication		5.4. Mobile Node Authentication
	G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through		G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through
	EAP authenticator.		EAP authenticator.
	G4.2 The AAA - HA interface SHOULD support authentication based on		G4.2 The AAA - HA interface MUST support authentication based on the
	the Mobility Message Authentication Options defined in [5].		Mobility Message Authentication Options defined in [5].
	G4.3 The HA SHOULD be able to request either the keying material to		G4.3 The AAAH MUST be able to provide a MN-HA key (or data used for
	generate MN-HA key for MN-HA Mobility Message Authentication		subsequent key derivation of the MN-HA key by the HA) to the HA if
	Option or SHOULD be able to request the MN-HA key and the related		requested. Additional data, such as the SPI or lifetime
	SPI values from the AAAH server.		parameters, are sent along with the keying material.
	G4.4 The HA SHOULD be able to request the AAAH server to		G4.4 The HA SHOULD be able to request the AAAH server to
	authenticate the MN with the value in the MN-AAA Mobility Message		authenticate the MN with the value in the MN-AAA Mobility Message
	Authentication Option.		Authentication Option.
	G4.5 The HA MUST include the Mobile Node Identifier option [7] in		G4.5 The HA MUST include an identifier of the mobile node in the AAA
	the AAA transactions with the AAAH server.		transactions with the AAAH server.
	G4.6 The AAAH server SHOULD be able to authenticate the MN
	identified by the value in the Mobile Node Identifier option using
	the value in MN-AAA Mobility Message Authentication Option and the
	corresponding value of the SPI.
	G4.7 If the MN-AAA Mobility Message Authentication Option is not
	included by the HA or the MN-AAA Mobility Message Authentication
	Option is included and the MN-AAA authentication is successful,
	the AAAH MUST send the keying material for MN-HA key to the HA if
	the HA requested for MN-HA keying material only. The AAAH MUST
	send the MN-HA key and the corresponding SPI value to the HA if
	the HA requested for MN-HA key and SPI.
	5.5. Provisioning of Configuration Parameters		5.5. Provisioning of Configuration Parameters
	o The HA SHOULD be able to communicate to the AAAH server the Home		o The HA SHOULD be able to communicate to the AAAH server the Home
	Address allocated to the MN and the FQDN of the MN (e.g., for		Address allocated to the MN and the FQDN of the MN (e.g., for
	allowing the AAAH server to perform a DNS update on behalf of the		allowing the AAAH server to perform a DNS update on behalf of the
	MN).		MN).
	o The AAAH SHOULD be able to indicate to the HA if the MN is		o The AAAH SHOULD be able to indicate to the HA if the MN is
	authorized to autoconfigure its Home Address.		authorized to autoconfigure its Home Address.
	6. Goals for the AAA-NAS interface		6. Goals for the AAA-NAS interface
	In the integrated scenario, the AAA server provides the HA		In the integrated scenario, the AAA server provides the HA
	information to the NAS as part of the whole AAA operations for		information to the NAS as part of the whole AAA operations for
	network access.		network access.
	G6.1 The AAAH server MUST be able to communicate the Home Agent		G6.1 The AAAH server MUST be able to communicate the Home Agent
	Information (IP Address or FQDN) to the NAS.		Information (IP Address or FQDN) to the NAS.
	G6.2 The NAS SHOULD be able to notify the AAAH of the		G6.2 The NAS MUST be able to notify the AAAH if it supports the AAA
	functionalities described in [4].		extensions designed to receive the HA assignment information
			described in [4].
	G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can		G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can
	allocate a Home Agent to the MN. Therefore the NAS SHOULD be able		allocate a Home Agent to the MN. Therefore the NAS SHOULD be able
	to include suggested HA address in the ASP in the NAS - AAA		to include suggested HA address in the ASP in the NAS - AAA
	interaction.		interaction.
	G6.4 The AAA server of the MSA MUST be able to indicate to the NAS		G6.4 The AAA server of the MSA MUST be able to indicate to the NAS
	whether the MN is authorized to use a local Home Agent (i.e. a		whether the MN is authorized to use a local Home Agent (i.e. a
	Home Agent in the ASP/MSP).		Home Agent in the ASP/MSP).
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 37 ¶
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Security Considerations		8. Security Considerations
	As stated in Section 5.1 the AAA-HA interface must provide mutual		As stated in Section 5.1 the AAA-HA interface must provide mutual
	authentication, integrity and replay protection. Furthermore, if		authentication, integrity and replay protection. Furthermore, if
	security parameters (e.g., IKE pre-shared key) are transferred		security parameters (e.g., IKE pre-shared key) are transferred
	through this interface, confidentiality is strongly recommended to be		through this interface, confidentiality is strongly recommended to be
	supported. In this case the links between the HA and the AAA server		supported. In this case the links between the HA and the AAA server
	of the MSA and between the NAS and the AAA server must be secure.		of the MSA and between the NAS and the AAA server MUST be secure.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank James Kempf, Alper Yegin, Vijay		The authors would like to thank James Kempf, Alper Yegin, Vijay
	Devarapalli, Basavaraj Patil, Gopal Dommety and Madjid Nakhjiri for		Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo and
	their comments and feedback. Moreover the authors would like to		Madjid Nakhjiri for their comments and feedback. Moreover the
	thank Hannes Tschofenig for his deep technical and editorial review		authors would like to thank Hannes Tschofenig for his deep technical
	of the draft. Finally the aithors would like to thank Kuntal		and editorial review of the draft. Finally the aithors would like to
	Chowdhury who contribbuted identifying the goals related to rfc4285		thank Kuntal Chowdhury who contribbuted identifying the goals related
	authentication.		to rfc4285 authentication.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping		[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
	Mobile IPv6 (MIPv6)", RFC 4640, September 2006.		Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
	[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6		[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
	Bootstrapping in Split Scenario", RFC 5026, October 2007.		Bootstrapping in Split Scenario", RFC 5026, October 2007.
	[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the		[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
	Integrated Scenario",		Integrated Scenario",
	draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in		draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
	progress), July 2007.		progress), April 2008.
	[5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,		[5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
	"Authentication Protocol for Mobile IPv6", RFC 4285,		"Authentication Protocol for Mobile IPv6", RFC 4285,
	January 2006.		January 2006.
	[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[6] 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.
	[7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,		[7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
	"Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",		"Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	December 2005.		December 2005.
	[9] Soliman, H., "Mobile IPv6 support for dual stack Hosts and		[9] Soliman, H., "Mobile IPv6 support for dual stack Hosts and
	Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in		Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in
	progress), November 2007.		progress), November 2007.
	Authors' Addresses		Authors' Addresses
	Gerardo Giaretta		Gerardo Giaretta
	Qualcomm		Qualcomm
	5995 Morehouse Drive		5775 Morehouse Drive
	San Diego, 92109		San Diego, 92109
	USA		USA
	Email: gerardog@qualcomm.com		Email: gerardo@qualcomm.com
	Ivano Guardini		Ivano Guardini
	Telecom Italia Lab		Telecom Italia Lab
	via G. Reiss Romoli, 274		via G. Reiss Romoli, 274
	TORINO, 10148		TORINO, 10148
	Italy		Italy
	Email: ivano.guardini@telecomitalia.it		Email: ivano.guardini@telecomitalia.it
	Elena Demaria		Elena Demaria
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, line 7 ¶
	Rafa Marin Lopez		Rafa Marin Lopez
	University of Murcia		University of Murcia
	30071 Murcia		30071 Murcia
	Spain		Spain
	Email: rafa@dif.um.es		Email: rafa@dif.um.es
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"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, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 12, line 44 ¶		skipping to change at line 504 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 30 change blocks.
	75 lines changed or deleted		59 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/