< draft-ietf-mip6-bootstrap-ps-02.txt		draft-ietf-mip6-bootstrap-ps-03.txt >
	MIP6 A. Patel, Editor		MIP6 A. Patel, Editor
	Internet-Draft Cisco		Internet-Draft Cisco
	Expires: September 16, 2005 March 18, 2005		Expires: January 15, 2006 July 14, 2005
	Problem Statement for bootstrapping Mobile IPv6		Problem Statement for bootstrapping Mobile IPv6
	draft-ietf-mip6-bootstrap-ps-02.txt		draft-ietf-mip6-bootstrap-ps-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		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
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 16, 2005.		This Internet-Draft will expire on January 15, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	A mobile node needs at least the following information: a home		A mobile node needs at least the following information: a home
	address, home agent address and a security association with home		address, home agent address and a security association with home
	agent to register with the home agent. The process of obtaining this		agent to register with the home agent. The process of obtaining this
	information is called bootstrapping. This document discuss the		information is called bootstrapping. This document discuss the
	issues involved with how the mobile node can be bootstrapped for		issues involved with how the mobile node can be bootstrapped for
	Mobile IPv6 and various potential deployment scenarios for		Mobile IPv6 and various potential deployment scenarios for
	bootstrapping the mobile node.		bootstrapping the mobile node.
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4		1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4
	1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10		5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10
	5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10		5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10
	5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11		5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11
	5.1.3 Management requirements . . . . . . . . . . . . . . . 12		5.1.3 Management requirements . . . . . . . . . . . . . . . 12
	5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 12		5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 13
	5.2.1 Integration with AAA Infrastructure . . . . . . . . . 12		5.2.1 Integration with AAA Infrastructure . . . . . . . . . 13
	5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13		5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13
	5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13		5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13
	5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13		5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13
	6. Network Access and Mobility services . . . . . . . . . . . . . 14		6. Network Access and Mobility services . . . . . . . . . . . . . 15
	7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16		7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 17
	7.1 Mobility Service Subscription Scenario . . . . . . . . . . 16		7.1 Mobility Service Subscription Scenario . . . . . . . . . . 17
	7.2 Integrated ASP network scenario . . . . . . . . . . . . . 16		7.2 Integrated ASP network scenario . . . . . . . . . . . . . 17
	7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 17		7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 18
	7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 18		7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 19
	8. Parameters for authentication . . . . . . . . . . . . . . . . 19		8. Parameters for authentication . . . . . . . . . . . . . . . . 20
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 21		9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 22
	9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 22		9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
	12.1 Normative References . . . . . . . . . . . . . . . . . . . . 25		13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . 28
	12.2 Informative References . . . . . . . . . . . . . . . . . . . 25		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26		14.1 Normative References . . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . . 27		14.2 Informative References . . . . . . . . . . . . . . . . . . 29
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . 30
			Intellectual Property and Copyright Statements . . . . . . . . 31
	1. Introduction		1. Introduction
	Mobile IPv6 [RFC3775] specifies mobility support based on the		Mobile IPv6 [RFC3775] specifies mobility support based on the
	assumption that a mobile node has a trust relationship with an entity		assumption that a mobile node has a trust relationship with an entity
	called the home agent. Once the home agent address has been learned		called the home agent. Once the home agent address has been learned
	for example via manual configuration, via anycast discovery		for example via manual configuration, via anycast discovery
	mechanisms, via DNS lookup; Mobile IPv6 signaling messages between		mechanisms, via DNS lookup; Mobile IPv6 signaling messages between
	the mobile node and the home agent are secured with IPsec or		the mobile node and the home agent are secured with IPsec or
	authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The		authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 43 ¶
	form of signalling) to do so etc.		form of signalling) to do so etc.
	Also, in certain scenarios, after the MN bootstraps for the first		Also, in certain scenarios, after the MN bootstraps for the first
	time (out of the box), subsequent bootstrapping is implementation		time (out of the box), subsequent bootstrapping is implementation
	dependent. For instance, the MN may bootstrap everytime it boots,		dependent. For instance, the MN may bootstrap everytime it boots,
	bootstrap everytime on prefix change, bootstrap periodically to		bootstrap everytime on prefix change, bootstrap periodically to
	anchor to an optimal (distance, load etc) HA, etc.		anchor to an optimal (distance, load etc) HA, etc.
	1.3 Terminology		1.3 Terminology
	General mobility terminology can be found in		General mobility terminology can be found in [I-D.ietf-seamoby-
	[I-D.ietf-seamoby-mobility]. The following additional terms are used		mobility]. The following additional terms are used here:
	here:
	Trust relationship		Trust relationship
	In the context of this draft, trust relationship means that two		In the context of this draft, trust relationship means that two
	parties in question, typically the user of the mobile host and the		parties in question, typically the user of the mobile host and the
	mobility or access service provider, have some sort of prior		mobility or access service provider, have some sort of prior
	contact in which the mobile host was provisioned with credentials.		contact in which the mobile host was provisioned with credentials.
	These credentials allow the mobile host to authenticate itself to		These credentials allow the mobile host to authenticate itself to
	the mobility or access service authorizer and to prove its		the mobility or access service authorizer and to prove its
	authorization to obtain service.		authorization to obtain service.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 25 ¶
	is one in which the user of the mobile host and the mobility or		is one in which the user of the mobile host and the mobility or
	access service provider have no previous contact and the mobile		access service provider have no previous contact and the mobile
	host is not required to supply credentials to authenticate and		host is not required to supply credentials to authenticate and
	prove authorization for service. Mobility and/or network access		prove authorization for service. Mobility and/or network access
	service is provided without any authentication or authorization.		service is provided without any authentication or authorization.
	Infrastructureless in this context does not mean that there is no		Infrastructureless in this context does not mean that there is no
	network infrastructure, such as would be the case for an ad hoc		network infrastructure, such as would be the case for an ad hoc
	network.		network.
	Credentials		Credentials
	Data or mechanism used by a mobile host to authenticate itself to		Data or mechanism used by a mobile host to authenticate itself to
	a mobility or access network service provider and prove		a mobility or access network service provider and prove
	authorization to receive service. User name/passwords, one time		authorization to receive service. User name/passwords, one time
	password cards, public/private key pairs with certificates,		password cards, public/private key pairs with certificates,
	biometric information, etc. are some examples.		biometric information, etc. are some examples.
	ASA		ASA
	Access Service Authorizer. A network operator that authenticates		Access Service Authorizer. A network operator that authenticates
	a mobile host and establishes the mobile host's authorization to		a mobile host and establishes the mobile host's authorization to
	receive Internet service.		receive Internet service.
	ASP		ASP
	Access Service Provider. A network operator that provides direct		Access Service Provider. A network operator that provides direct
	IP packet forwarding to and from the end host.		IP packet forwarding to and from the end host.
	Serving Network Access Provider		Serving Network Access Provider
	A network operator that is the mobile host's ASP but not its ASA.		A network operator that is the mobile host's ASP but not its ASA.
	The serving network accesss provider may or may not additionally		The serving network accesss provider may or may not additionally
	provide mobility service.		provide mobility service.
	Home Network Access Provider		Home Network Access Provider
	A network operator that is both the mobile host's ASP and ASA.		A network operator that is both the mobile host's ASP and ASA.
	The home network access provider may or may not additionally		The home network access provider may or may not additionally
	provide mobility service (note that this is a slighlty different		provide mobility service (note that this is a slighlty different
	definition from RFC 3775).		definition from RFC 3775).
	skipping to change at page 16, line 16 ¶		skipping to change at page 17, line 16 ¶
	This section describes the various network deployment scenarios. The		This section describes the various network deployment scenarios. The
	various combinations of service providers as described in Section 6		various combinations of service providers as described in Section 6
	are considered.		are considered.
	For each scenario, the underlying assumptions are described. The		For each scenario, the underlying assumptions are described. The
	basic assumption is that there is a trust relationship between mobile		basic assumption is that there is a trust relationship between mobile
	user and the MSP. Typically, this trust relationship is between the		user and the MSP. Typically, this trust relationship is between the
	mobile user and AAA in the MSA's network. Seed information needed to		mobile user and AAA in the MSA's network. Seed information needed to
	bootstrap the mobile node is considered in two cases:		bootstrap the mobile node is considered in two cases:
	o AAA authentication is mandatory for network access		o AAA authentication is mandatory for network access
	o AAA authentication is not part of network access. The seed		o AAA authentication is not part of network access. The seed
	information is described further in Section 8.		information is described further in Section 8.
	7.1 Mobility Service Subscription Scenario		7.1 Mobility Service Subscription Scenario
	Many commercial deployments are based on the assumption that mobile		Many commercial deployments are based on the assumption that mobile
	nodes have a subscription with a service provider. In particular, in		nodes have a subscription with a service provider. In particular, in
	this scenario the MN has a subscription with an MSP, called the home		this scenario the MN has a subscription with an MSP, called the home
	MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is		MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is
	responsible of setting up a home agent on a subnet that acts as a		responsible of setting up a home agent on a subnet that acts as a
	Mobile IPv6 home link. As a consequence, the home MSP should		Mobile IPv6 home link. As a consequence, the home MSP should
	explicitly authorize and control the whole bootstrapping procedure.		explicitly authorize and control the whole bootstrapping procedure.
	Since the MN is assumed to have a pre-established trust relationship		Since the MN is assumed to have a pre-established trust relationship
	with its home provider, it must be configured with an identity and		with its home provider, it must be configured with an identity and
	credentials, for instance an NAI and a shared secret by some		credentials, for instance an NAI and a shared secret by some out-of-
	out-of-band means before bootstrapping, for example by manual		band means before bootstrapping, for example by manual configuration.
	configuration.
	In order to guarantee ubiquitous service, the MN should be able to		In order to guarantee ubiquitous service, the MN should be able to
	bootstrap MIPv6 operations with its home MSP from any possible access		bootstrap MIPv6 operations with its home MSP from any possible access
	location, such as an open network or a network managed by an ASP,		location, such as an open network or a network managed by an ASP,
	that may be different from the MSP and may not have any		that may be different from the MSP and may not have any pre-
	pre-established trust relationship with it.		established trust relationship with it.
	7.2 Integrated ASP network scenario		7.2 Integrated ASP network scenario
	In this scenario, the ASP and MSP are the same ASP. MN shares		In this scenario, the ASP and MSP are the same ASP. MN shares
	security credentials for access to the network and these credentials		security credentials for access to the network and these credentials
	can be used to bootstrap MIPv6. This bootstrapping can be done		can be used to bootstrap MIPv6. This bootstrapping can be done
	during the same phase as access authentication/authorization or at a		during the same phase as access authentication/authorization or at a
	later time (probably based on some state created during access		later time (probably based on some state created during access
	authentication/authorization).		authentication/authorization).
	Figure 1 describes an example AAA design for integrated ASP scenario.		Figure 1 describes an example AAA design for integrated ASP scenario.
	+----------------------------+		+----------------------------+
	| IASP(ASP+MSP) |		| IASP(ASP+MSP) |
	+----+ +-----+ +----+ |		+----+ +-----+ +----+ |
	| MN |--- | NAS | | HA | |		| MN |--- | NAS | | HA | |
	+----+ +-----+ +----+ |		+----+ +-----+ +----+ |
	| \ \ |		| \ \ |
	| \ +------+ \ +-------+ |		| \ +------+ \ +-------+ |
	| -|AAA-NA| -|AAA-MIP| |		| -|AAA-NA| -|AAA-MIP| |
	| +------+ +-------+ |		| +------+ +-------+ |
	+----------------------------+		+----------------------------+
	NAS: Network Access Server		NAS: Network Access Server
	AAA-NA: AAA for network access		AAA-NA: AAA for network access
	AAA-MIP: AAA for Mobile IP service		AAA-MIP: AAA for Mobile IP service
	Figure 1: Integrated ASP network		Figure 1: Integrated ASP network
	7.3 Third party MSP scenario		7.3 Third party MSP scenario
	Mobility service has traditionally been provided by the same entity		Mobility service has traditionally been provided by the same entity
	that authenticates and authorizes the subscriber for network access.		that authenticates and authorizes the subscriber for network access.
	This is certainly the only model support by the base Mobile IPv6		This is certainly the only model support by the base Mobile IPv6
	specification.		specification.
	In the 3rd party mobility service provider scenario, the subscription		In the 3rd party mobility service provider scenario, the subscription
	for mobility service is made with one entity (home MSA for instance a		for mobility service is made with one entity (home MSA for instance a
	skipping to change at page 18, line 5 ¶		skipping to change at page 19, line 5 ¶
	the serving MSP). These two entities have a trust relationship.		the serving MSP). These two entities have a trust relationship.
	Transitive trust among the mobile node and these two entities may be		Transitive trust among the mobile node and these two entities may be
	used to assure the participants that they are dealing with, are		used to assure the participants that they are dealing with, are
	trustworthy peers.		trustworthy peers.
	This arrangement is similar to the visited - home operator roaming		This arrangement is similar to the visited - home operator roaming
	arrangement for network access.		arrangement for network access.
	Figure 2 describes an example network for third party MSP scenario.		Figure 2 describes an example network for third party MSP scenario.
	+--------------+ +--------+		+--------------+ +--------+
	| | |Serving |		| | |Serving |
	| ASP | | MSP |		| ASP | | MSP |
	+----+ +-----+ | | +----+ |		+----+ +-----+ | | +----+ |
	| MN |--- | NAS | | | | HA | | +-------------------+		| MN |--- | NAS | | | | HA | | +-------------------+
	+----+ +-----+ |===| +----+ | | Home MSP |		+----+ +-----+ |===| +----+ | | Home MSP |
	| \ | | \ | | (e.g.corporate NW)|		| \ | | \ | | (e.g.corporate NW)|
	| \ +------+ | | \ | +-------+ |		| \ +------+ | | \ | +-------+ |
	| -|AAA-NA| | | -------|AAA-MIP| |		| -|AAA-NA| | | -------|AAA-MIP| |
	| +------+ | | | | +-------+ |		| +------+ | | | | +-------+ |
	+------------ + +--------+ +-------------------+		+------------ + +--------+ +-------------------+
	Figure 2: Third Party MSP network		Figure 2: Third Party MSP network
	7.4 Infrastructure-less scenario		7.4 Infrastructure-less scenario
	Infrastructure refers to network entities like AAA, PKI, HLR etc.		Infrastructure refers to network entities like AAA, PKI, HLR etc.
	Infrastructure-less implies that there is no dependency on any		Infrastructure-less implies that there is no dependency on any
	elements in the network with which the user has any form of trust		elements in the network with which the user has any form of trust
	relationship.		relationship.
	In such a scenario, there is absolutely no relationship between host		In such a scenario, there is absolutely no relationship between host
	and infrastructure.		and infrastructure.
	skipping to change at page 22, line 22 ¶		skipping to change at page 23, line 23 ¶
	at the time the SA is created or dynamically managed through a first		at the time the SA is created or dynamically managed through a first
	come, first served allocation policy.		come, first served allocation policy.
	9.2 Threats to the Bootstrapping Process		9.2 Threats to the Bootstrapping Process
	Various attacks are possible on the bootstrapping process itself.		Various attacks are possible on the bootstrapping process itself.
	These attacks can compromise the process such that the RFC 3775		These attacks can compromise the process such that the RFC 3775
	requirements for Mobile IP security are not met, or they can serve to		requirements for Mobile IP security are not met, or they can serve to
	simply disrupt the process such that bootstrapping cannot complete.		simply disrupt the process such that bootstrapping cannot complete.
	Here are some possible attacks:		Here are some possible attacks:
	o An attacking network entity purporting to offer the mobile host a		o An attacking network entity purporting to offer the mobile host a
	legitimate home agent address or boostrapping for the IPsec SAs		legitimate home agent address or boostrapping for the IPsec SAs
	may, instead, offer a bogus home agent address or configure bogus		may, instead, offer a bogus home agent address or configure bogus
	SAs that allow the home agent to steal the mobile host's traffic		SAs that allow the home agent to steal the mobile host's traffic
	or otherwise disrupts the mobile host's mobility service.		or otherwise disrupts the mobile host's mobility service.
	o An attacking mobile host may attempt to steal mobility service by		o An attacking mobile host may attempt to steal mobility service by
	offering up fake credentials to a bootstrapping network entity or		offering up fake credentials to a bootstrapping network entity or
	otherwise disrupt the home agent's ability to offer mobility		otherwise disrupt the home agent's ability to offer mobility
	service.		service.
	o A man in the middle on the link between the mobile host and the		o A man in the middle on the link between the mobile host and the
	bootstrapping network entity could steal credentials or other		bootstrapping network entity could steal credentials or other
	sensitive information and use that to steal mobility service or		sensitive information and use that to steal mobility service or
	deny it to the legitimate owner of the credentials. Refer to		deny it to the legitimate owner of the credentials. Refer to
	Section 7.15 in [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] for		Section 7.15 in [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] for
	further information.		further information.
	o An attacker could arrange for a distributed denial of service		o An attacker could arrange for a distributed denial of service
	attack on the bootstrapping entity, to disrupt legitimate users		attack on the bootstrapping entity, to disrupt legitimate users
	from bootstrapping.		from bootstrapping.
	In addition to these attacks, there are other considerations that are		In addition to these attacks, there are other considerations that are
	important in achieving a good security design. As mobility and		important in achieving a good security design. As mobility and
	network access authentication are separate services, keys generated		network access authentication are separate services, keys generated
	for these services need to be cryptographically separate, separately		for these services need to be cryptographically separate, separately
	named, and have separate lifetimes, including if the keys are		named, and have separate lifetimes, including if the keys are
	generated from the same authentication credentials This is necessary		generated from the same authentication credentials This is necessary
	because a mobile host must be able to move from one serving (or		because a mobile host must be able to move from one serving (or
	roaming) network access provider to another without needing to change		roaming) network access provider to another without needing to change
	its mobility access provider. Finally, basic cryptographic processes		its mobility access provider. Finally, basic cryptographic processes
	must provide for multiple algorithms in order to accommodate the		must provide for multiple algorithms in order to accommodate the
	widely varying deployment needs.		widely varying deployment needs.
	10. Contributors		10. IANA Considerations
			No new protocol numbers are required.
			11. Contributors
	This contribution is a joint effort of the problem statement design		This contribution is a joint effort of the problem statement design
	team of the Mobile IPv6 WG. The contributors include Basavaraj		team of the Mobile IPv6 WG. The contributors include Basavaraj
	Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,		Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
	Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,		Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,
	Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay		Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay
	Devarapalli, Kuntal Chowdury.		Devarapalli, Kuntal Chowdury.
	The design team members can be reached at:		The design team members can be reached at:
	Basavaraj Patil basavaraj.patil@nokia.com		Basavaraj Patil basavaraj.patil@nokia.com
	Gerardo Giaretta gerardo.giaretta@tilab.com		Gerardo Giaretta gerardo.giaretta@tilab.com
	Jari Arkko jari.arkko@kolumbus.fi		Jari Arkko jari.arkko@kolumbus.fi
	James Kempf kempf@docomolabs-usa.com		James Kempf kempf@docomolabs-usa.com
	Yoshihiro Ohba yohba@tari.toshiba.com		Yoshihiro Ohba yohba@tari.toshiba.com
	Ryuji Wakikawa ryuji@sfc.wide.ad.jp		Ryuji Wakikawa ryuji@sfc.wide.ad.jp
	Hiroyuki Ohnishi ohnishi.hiroyuki@lab.ntt.co.jp		Hiroyuki Ohnishi ohnishi.hiroyuki@lab.ntt.co.jp
	Mayumi Yanagiya yanagiya.mayumi@lab.ntt.co.jp		Mayumi Yanagiya yanagiya.mayumi@lab.ntt.co.jp
	Samita Chakrabarti Samita.Chakrabarti@eng.sun.com		Samita Chakrabarti Samita.Chakrabarti@eng.sun.com
	Gopal Dommety gdommety@cisco.com		Gopal Dommety gdommety@cisco.com
	Kent Leung kleung@cisco.com		Kent Leung kleung@cisco.com
	Alper Yegin alper.yegin@samsung.com		Alper Yegin alper.yegin@samsung.com
	Hannes Tschofenig hannes.tschofenig@siemens.com		Hannes Tschofenig hannes.tschofenig@siemens.com
	Vijay Devarapalli vijayd@iprg.nokia.com		Vijay Devarapalli vijayd@iprg.nokia.com
	Kuntal Chowdury kchowdury@starentnetworks.com		Kuntal Chowdury kchowdury@starentnetworks.com
	11. Acknowledgments		12. Acknowledgments
	Special thanks to James Kempf and Jari Arkko for writing the initial		Special thanks to James Kempf and Jari Arkko for writing the initial
	version of the bootstrapping statement. Thanks to John Loughney for		version of the bootstrapping statement. Thanks to John Loughney for
	a detailed editorial review.		a detailed editorial review.
	12. References		13. IPR Disclosure Acknowledgement
	12.1 Normative References		By submitting this Internet-Draft, each author represents that any
			applicable patent or other IPR claims of which he or she is aware
			have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
			14. References
			14.1 Normative References
	[I-D.ietf-mip6-mn-auth-protocol-02]		[I-D.ietf-mip6-mn-auth-protocol-02]
	Patel et. al., A., "Authentication Protocol for Mobile		Patel et. al., A., "Authentication Protocol for Mobile
	IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in		IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in
	progress), November 2004,		progress), November 2004,
			<draft-ietf-mip6-auth-protocol-02.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-02.txt>
	.
	[I-D.ietf-seamoby-mobility]		[I-D.ietf-seamoby-mobility]
	Manner, J. and M. Kojo, "Mobility Related Terminology",		Manner, J. and M. Kojo, "Mobility Related Terminology",
	draft-ietf-seamoby-mobility-terminology-06 (work in		draft-ietf-seamoby-mobility-terminology-06 (work in
	progress), February 2004,		progress), February 2004,
			<draft-ietf-seamoby-mobility-terminology-06.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology
	-06.txt>
	.
	[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access		[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
	Identifier Extension for IPv4", RFC 2794, March 2000.		Identifier Extension for IPv4", RFC 2794, March 2000.
	[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to		[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
	Protect Mobile IPv6 Signaling Between Mobile Nodes and		Protect Mobile IPv6 Signaling Between Mobile Nodes and
	Home Agents", RFC 3776, June 2004.		Home Agents", RFC 3776, June 2004.
	12.2 Informative References		14.2 Informative References
	[2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol		[2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol
	(EAP)", February 2004,		(EAP)", February 2004, <draft-ietf-eap-rfc2284bis-09.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-09.txt>
	.
	[I-D.giaretta-mip6-authorization-eap]		[I-D.giaretta-mip6-authorization-eap]
	Giaretta, G., "MIPv6 Authorization and Configuration based		Giaretta, G., "MIPv6 Authorization and Configuration based
	on EAP", draft-giaretta-mip6-authorization-eap-00 (work in		on EAP", draft-giaretta-mip6-authorization-eap-00 (work in
	progress), February 2004,		progress), February 2004,
			<draft-giaretta-mip6-authorization-eap-00.txt>.
	<http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-0
	0.txt>
	.
	[I-D.ietf-mip6-mn-ident-option-02]		[I-D.ietf-mip6-mn-ident-option-02]
	Patel, A., Leung, K., Akthar, H., Khalil, M. and K.		Patel, A., Leung, K., Akthar, H., Khalil, M., and K.
	Chowdhury, "Mobile Node Identifier Option for Mobile		Chowdhury, "Mobile Node Identifier Option for Mobile
	IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in		IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in
	progress), February 2004,		progress), February 2004,
			<draft-ietf-mip6-mn-ident-option-02.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt>
	.
	[I-D.kempf-mip6-bootstrap]		[I-D.kempf-mip6-bootstrap]
	Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping		Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping
	Problem", draft-kempf-mip6-bootstrap-00 (work in		Problem", draft-kempf-mip6-bootstrap-00 (work in
	progress), March 2004,		progress), March 2004,
			<draft-kempf-mip6-bootstrap-00.txt>.
	<http://www.ietf.org/internet-drafts/draft-kempf-mip6-bootstrap-00.txt>
	.
	[I-D.mariblanca-aaa-eap-lla-00]		[I-D.mariblanca-aaa-eap-lla-00]
	Mariblanca, D., "EAP lower layer attributes for AAA		Mariblanca, D., "EAP lower layer attributes for AAA
	protocols", May 2004,		protocols", May 2004,
			<draft-mariblanca-aaa-eap-lla-00.txt>.
	<http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt>
	.
	[I-D.rosec]		[I-D.rosec]
	Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.		Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
	Nordmark, "Mobile IP version 6 Route Optimization Security		Nordmark, "Mobile IP version 6 Route Optimization Security
	Design Background", draft-ietf-mip6-ro-sec-02 (work in		Design Background", draft-ietf-mip6-ro-sec-02 (work in
	progress), October 2004,		progress), October 2004, <draft-ietf-mip6-ro-sec-02.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt>
	.
	[eap_keying]		[eap_keying]
	Aboba et. al., B., "Extensible Authentication Protocol		Aboba et. al., B., "Extensible Authentication Protocol
	(EAP) Key Management Framework",		(EAP) Key Management Framework",
	draft-ietf-eap-keying-05.txt (work in progress), February		draft-ietf-eap-keying-05.txt (work in progress),
	2005,		February 2005, <draft-ietf-eap-keying-05.txt>.
	<http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt>
	.
	Author's Address		Author's Address
	Alpesh Patel		Alpesh Patel
	Cisco		Cisco
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone: +1 408 853 9580		Phone: +1 408 853 9580
	EMail: alpesh@cisco.com		Email: alpesh@cisco.com
	Intellectual Property Statement		Intellectual Property Statement
	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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 62 change blocks.
	123 lines changed or deleted		121 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/