< draft-ietf-nemo-multihoming-issues-05.txt		draft-ietf-nemo-multihoming-issues-06.txt >
	NEMO Working Group C. Ng		NEMO Working Group C. Ng
	Internet-Draft Panasonic Singapore Labs		Internet-Draft Panasonic Singapore Labs
	Expires: August 27, 2006 E. Paik		Expires: December 24, 2006 E. Paik
	KT		KT
	T. Ernst		T. Ernst
	Keio University / WIDE		INRIA
	M. Bagnulo		M. Bagnulo
	UC3M		UC3M
	February 23, 2006		June 22, 2006
	Analysis of Multihoming in Network Mobility Support		Analysis of Multihoming in Network Mobility Support
	draft-ietf-nemo-multihoming-issues-05		draft-ietf-nemo-multihoming-issues-06
	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 39 ¶		skipping to change at page 1, line 39 ¶
	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 August 27, 2006.		This Internet-Draft will expire on December 24, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document is an analysis of multihoming in the context of network		This document is an analysis of multihoming in the context of network
	mobility (NEMO) in IPv6. As there are many situations in which		mobility (NEMO) in IPv6. As there are many situations in which
	mobile networks may be multihomed, a taxonomy is proposed to classify		mobile networks may be multihomed, a taxonomy is proposed to classify
	the possible configurations. The possible deployment scenarios of		the possible configurations. The possible deployment scenarios of
	multihomed mobile networks are described together with the associated		multihomed mobile networks are described together with the associated
	issues when network mobility is supported by RFC 3963 (NEMO Basic		issues when network mobility is supported by RFC 3963 (NEMO Basic
	Support). Recommendations are then made as to whether the NEMO		Support). Recommendations are offered on how to address these
	Working Group should solve these issues, or a solution should be		issues.
	sought elsewhere.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7		2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7
	2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 8		2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 8
	2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8		2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8
	2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9		2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9
	skipping to change at page 3, line 4 ¶		skipping to change at page 2, line 49 ¶
	4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25		4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25
	4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26		4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26
	4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 26		4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 26
	4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26		4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26
	5. Recommendations to the Working Group . . . . . . . . . . . . . 28		5. Recommendations to the Working Group . . . . . . . . . . . . . 28
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 32		10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	10.2. Informative References . . . . . . . . . . . . . . . . . . 32		10.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Appendix A. Alternative Classifications Approach . . . . . . . . 35		Appendix A. Alternative Classifications Approach . . . . . . . . 35
	A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35		A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35
	A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35		A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35
	A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36		A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	Using NEMO Basic Support, this would translate into having multiple		Using NEMO Basic Support, this would translate into having multiple
	bi-directional tunnels between the MR(s) and the corresponding HA,		bi-directional tunnels between the MR(s) and the corresponding HA,
	and may result into multiple MNPs available to the MNNs. However,		and may result into multiple MNPs available to the MNNs. However,
	NEMO Basic Support does not specify any particular mechanism to		NEMO Basic Support does not specify any particular mechanism to
	manage multiple bi-directional tunnels. The objective of this memo		manage multiple bi-directional tunnels. The objective of this memo
	is thus multi-folded:		is thus multi-folded:
	o to determine all the potential multihomed configurations for a		o to determine all the potential multihomed configurations for a
	NEMO, and then to identify which of those may be useful in a real		NEMO, and then to identify which of those may be useful in a real
	life scenario,		life scenario;
	o to capture issues that may prevent some multihomed configurations		o to capture issues that may prevent some multihomed configurations
	to be supported under the operation of NEMO Basic Support. It		to be supported under the operation of NEMO Basic Support. It
	doesn't necessarily mean that those not supported will not work		doesn't necessarily mean that those not supported will not work
	with NEMO Basic Support, as it may be up to the implementors to		with NEMO Basic Support, as it may be up to the implementors to
	make it work (hopefully this memo will be helpful to these		make it work (hopefully this memo will be helpful to these
	implementors).		implementors);
	o to identify potential solutions to the previously identified		o to identify potential solutions to the previously identified
	issues.		issues; and
	o to decide which issues are worth to be solved, and to determine		o to decide which issues are worth to be solved, and to determine
	which WG should address each of the issues that are worth solving.		which WG should address each of the issues that are worth solving.
	In order to reach these objectives, a taxonomy to classify the		In order to reach these objectives, a taxonomy to classify the
	possible multihomed configurations is described in Section 2.		possible multihomed configurations is described in Section 2.
	Deployment scenarios, their benefits, and requirements to meet these		Deployment scenarios, their benefits, and requirements to meet these
	benefits are illustrated in Section 3. Following this, the related		benefits are illustrated in Section 3. Following this, the related
	issues are studied in Section 4. The issues are then summarized in a		issues are studied in Section 4. The issues are then summarized in a
	matrix for each of the deployment scenario, and recommendations are		matrix for each of the deployment scenario, and recommendations are
	made on which of the issues should be worked on and where in		made on which of the issues should be worked on and where in
	Section 5. This memo concludes with an evaluation of NEMO Basic		Section 5. This memo concludes with an evaluation of NEMO Basic
	Support for multihomed configurations. Alternative classifications		Support for multihomed configurations. Alternative classifications
	are outlined in the Appendix.		are outlined in the Appendix.
	The readers should note that this document considers multihoming only		The readers should note that this document considers multihoming only
	from the point of view of an IPv6 environment. In order to		from the point of view of an IPv6 environment. In order to
	understand this memo, the reader is expected to be familiar with the		understand this memo, the reader is expected to be familiar with the
	above cited documents, i.e. with the NEMO terminology as defined in		above cited documents, i.e. with the NEMO terminology as defined in
	[2] (section 3) and [3], Goals and Benefits of Multihoming [6], Goals		[2] (section 3) and [3], Motivations and and Scenarios for
	and Requirements of Network Mobility Support [1], and the NEMO Basic		Multihoming [6], Goals and Requirements of Network Mobility Support
	Support specification [4]. Goals and benefits of multihoming as		[1], and the NEMO Basic Support specification [4]. Goals and
	discussed in [6] are applicable to fixed nodes, mobile nodes, fixed		benefits of multihoming as discussed in [6] are applicable to fixed
	networks and mobile networks.		nodes, mobile nodes, fixed networks and mobile networks.
	2. Classification		2. Classification
	As there are several configurations in which mobile networks are		As there are several configurations in which mobile networks are
	multihomed, there is a need to classify them into a clearly defined		multihomed, there is a need to classify them into a clearly defined
	taxonomy. This can be done in various ways. A Configuration-		taxonomy. This can be done in various ways. A Configuration-
	Oriented taxonomy is described in this section. Two other		Oriented taxonomy is described in this section. Two other
	taxonomies, namely, the Ownership-Oriented Approach, and the Problem-		taxonomies, namely, the Ownership-Oriented Approach, and the Problem-
	Oriented Approach are outlined in Appendix A.1 and Appendix A.2.		Oriented Approach are outlined in Appendix A.1 and Appendix A.2.
	skipping to change at page 6, line 52 ¶		skipping to change at page 6, line 52 ¶
	It can be seen that the above three parameters are fairly orthogonal		It can be seen that the above three parameters are fairly orthogonal
	to one another. Thus different values of 'x', 'y' and 'z' result		to one another. Thus different values of 'x', 'y' and 'z' result
	into different combinations of the 3-tuple (x,y,z).		into different combinations of the 3-tuple (x,y,z).
	As described in the sub-sections below, a total of 8 possible		As described in the sub-sections below, a total of 8 possible
	configurations can be identified. One thing the reader has to keep		configurations can be identified. One thing the reader has to keep
	in mind is that in each of the following 8 cases, the MR may be		in mind is that in each of the following 8 cases, the MR may be
	multihomed if either (i) multiple prefixes are available (on the home		multihomed if either (i) multiple prefixes are available (on the home
	link, or on the visited link), or (ii) the MR is equipped with		link, or on the visited link), or (ii) the MR is equipped with
	multiple interfaces. In such a case, the MR would have multiple Home		multiple interfaces. In such a case, the MR would have multiple HoA-
	Address / Care-of Address pairs. Issues pertaining to a multihomed		CoA pairs. Issues pertaining to a multihomed MR are also addressed
	MR are also addressed in [7]. In addition, the readers should also		in [7]. In addition, the readers should also keep in mind that when
	keep in mind that when "MNP(s) is/are available in the NEMO", the		"MNP(s) is/are available in the NEMO", the MNP(s) may either be
	MNP(s) may either be explicitly announced by the MR via router		explicitly announced by the MR via router advertisement, or made
	advertisement, or made available through Dynamic Host Configuration		available through Dynamic Host Configuration Protocol (DHCP).
	Protocol (DHCP).
	2.1. (1,1,1): Single MR, Single HA, Single MNP		2.1. (1,1,1): Single MR, Single HA, Single MNP
	The (1,1,1) configuration has only one MR, it is associated with a		The (1,1,1) configuration has only one MR, it is associated with a
	single HA, and a single MNP is available in the NEMO. To fall into a		single HA, and a single MNP is available in the NEMO. To fall into a
	multihomed configuration, at least one of the following conditions		multihomed configuration, at least one of the following conditions
	must hold:		must hold:
	o The MR has multiple interfaces and thus its has multiple CoAs;		o The MR has multiple interfaces and thus its has multiple CoAs;
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 34 ¶
	Note that the case where multiple prefixes are available on the		Note that the case where multiple prefixes are available on the
	visited link does not have any bearing on the MNPs. MNPs are		visited link does not have any bearing on the MNPs. MNPs are
	independent of prefixes available on the link where MR is attached,		independent of prefixes available on the link where MR is attached,
	thus prefixes available on the foreign link are not announced on the		thus prefixes available on the foreign link are not announced on the
	NEMO link. For the case where multiple prefixes are available on the		NEMO link. For the case where multiple prefixes are available on the
	home link, these are only announced on the NEMO link if the MR is		home link, these are only announced on the NEMO link if the MR is
	configured to do so. In this configuration, only one MNP is		configured to do so. In this configuration, only one MNP is
	announced.		announced.
	A bi-directional tunnel would then be established between each pair		A bi-directional tunnel would then be established between each HoA-
	of Home Address / Care-of Address.		CoA pair.
	Regarding MNNs, they are (usually) not multihomed since they would		Regarding MNNs, they are (usually) not multihomed since they would
	configure a single global address from the single MNP available on		configure a single global address from the single MNP available on
	the link they are attached to.		the link they are attached to.
	_____		_____
	_ p _ | |		_ p _ | |
	|_|-|<-_ |-|_|-| |-| _		|_|-|<-_ |-|_|-| |-| _
	_ |-|_|=| |_____| | _ |-|_|		_ |-|_|=| |_____| | _ |-|_|
	|_|-| | |-|_|-|		|_|-| | |-|_|-|
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP		Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
	2.2. (1,1,n): Single MR, Single HA, Multiple MNPs		2.2. (1,1,n): Single MR, Single HA, Multiple MNPs
	The (1,1,n) configuration has only one MR, it is associated with a		The (1,1,n) configuration has only one MR, it is associated with a
	single HA and two or more MNPs are available in the NEMO.		single HA and two or more MNPs are available in the NEMO.
	The MR may itself be multihomed, as detailed in Section 2.1. In such		The MR may itself be multihomed, as detailed in Section 2.1. In such
	a case, a bi-directional tunnel would be established between each		a case, a bi-directional tunnel would be established between each
	pair of Home Address / Care-of Address.		HoA-CoA pair.
	Regarding MNNs, they are multihomed because several MNPs are		Regarding MNNs, they are multihomed because several MNPs are
	available on the link they are attached to. The MNNs would then		available on the link they are attached to. The MNNs would then
	configure a global address with each MNP available on the link.		configure a global address with each MNP available on the link.
	_____		_____
	_ p1,p2 _ | |		_ p1,p2 _ | |
	|_|-|<-_ |-|_|-| |-| _		|_|-|<-_ |-|_|-| |-| _
	_ |-|_|=| |_____| | _ |-|_|		_ |-|_|=| |_____| | _ |-|_|
	|_|-| | |-|_|-|		|_|-| | |-|_|-|
	|		|
	MNNs MR AR Internet AR HA		MNNs MR AR Internet AR HA
	Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs		Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
	2.3. (1,n,1): Single MR, Multiple HAs, Single MNP		2.3. (1,n,1): Single MR, Multiple HAs, Single MNP
	The (1,n,1) configuration has only one MR and a single MNP is		The (1,n,1) configuration has only one MR and a single MNP is
	available in the NEMO. The MR, however, is associated with multiple		available in the NEMO. The MR, however, is associated with multiple
	HAs, possibly one HA per Home Address, or one HA per egress		HAs, possibly one HA per HoA, or one HA per egress interface.
	interface.
	The NEMO is multihomed since it has multiple HAs, but in addition the		The NEMO is multihomed since it has multiple HAs, but in addition the
	conditions detailed in Section 2.1 may also hold for the MR. A bi-		conditions detailed in Section 2.1 may also hold for the MR. A bi-
	directional tunnel would then be established between each pair of		directional tunnel would then be established between each HoA-CoA
	Home Address / Care-of Address.		pair.
	Regarding MNNs, they are (usually) not multihomed since they would		Regarding MNNs, they are (usually) not multihomed since they would
	configure a single global address from the single MNP available on		configure a single global address from the single MNP available on
	the link they are attached to.		the link they are attached to.
	AR HA2		AR HA2
	_ |		_ |
	|-|_|-| _		|-|_|-| _
	_____ | |-|_|		_____ | |-|_|
	_ p _ | |-|		_ p _ | |-|
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs		2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs
	The (1,n,n) configuration has only one MR. However, the MR is		The (1,n,n) configuration has only one MR. However, the MR is
	associated with multiple HAs, possibly one per Home Address (or one		associated with multiple HAs, possibly one per Home Address (or one
	HA per egress interface), and more than one MNP is available in the		HA per egress interface), and more than one MNP is available in the
	NEMO.		NEMO.
	The MR is multihomed since it has multiple HAs, but in addition the		The MR is multihomed since it has multiple HAs, but in addition the
	conditions detailed in Section 2.1 may also hold. A bi-directional		conditions detailed in Section 2.1 may also hold. A bi-directional
	tunnel would then be established between each pair of Home Address /		tunnel would then be established between each HoA-CoA pair.
	Care-of Address.
	Regarding MNNs, they are generally multihomed since they would		Regarding MNNs, they are generally multihomed since they would
	configure a global address from each MNP available on the link they		configure a global address from each MNP available on the link they
	are attached to.		are attached to.
	AR HA2		AR HA2
	_ | _		_ | _
	_____ |-|_|-|-|_|		_____ |-|_|-|-|_|
	_ p1,p2 _ | |-| |		_ p1,p2 _ | |-| |
	|_|-|<-_ |-|_|-| | _		|_|-|<-_ |-|_|-| | _
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 13 ¶
	Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs		Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
	2.5. (n,1,1): Multiple MRs, Single HA, Single MNP		2.5. (n,1,1): Multiple MRs, Single HA, Single MNP
	The (n,1,1) configuration has more than one MR advertising global		The (n,1,1) configuration has more than one MR advertising global
	routes. However, the MR(s) are associated with as single HA, and		routes. However, the MR(s) are associated with as single HA, and
	there in a single MNP available in the NEMO.		there in a single MNP available in the NEMO.
	The NEMO is multihomed since it has multiple MRs, but in addition the		The NEMO is multihomed since it has multiple MRs, but in addition the
	conditions detailed in Section 2.1 may also hold for each MR. A bi-		conditions detailed in Section 2.1 may also hold for each MR. A bi-
	directional tunnel would then be established between each pair of		directional tunnel would then be established between each HoA-CoA
	Home Address / Care-of Address.		pair.
	Regarding MNNs, they are (usually) not multihomed since they would		Regarding MNNs, they are (usually) not multihomed since they would
	configure a single global address from the single MNP available on		configure a single global address from the single MNP available on
	the link they are attached to.		the link they are attached to.
	MR2		MR2
	p<-_ |		p<-_ |
	_ |-|_|-| _____		_ |-|_|-| _____
	|_|-| |-| |		|_|-| |-| |
	_ | | |-| _		_ | | |-| _
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 40 ¶
	Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP		Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
	2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs		2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs
	The (n,1,n) configuration has more than one MR; multiple global		The (n,1,n) configuration has more than one MR; multiple global
	routes are advertised by the MRs and multiple MNPs are available		routes are advertised by the MRs and multiple MNPs are available
	within the NEMO.		within the NEMO.
	The NEMO is multihomed since it has multiple MRs, but in addition the		The NEMO is multihomed since it has multiple MRs, but in addition the
	conditions detailed in Section 2.1 may also hold for each MR. A bi-		conditions detailed in Section 2.1 may also hold for each MR. A bi-
	directional tunnel would then be established between each pair of		directional tunnel would then be established between each HoA-CoA
	Home Address / Care-of Address.		pair.
	Regarding MNNs, they are generally multihomed since they would		Regarding MNNs, they are generally multihomed since they would
	configure a global address from each MNP available on the link they		configure a global address from each MNP available on the link they
	are attached to.		are attached to.
	MR2		MR2
	p2<-_ |		p2<-_ |
	_ |-|_|-| _____		_ |-|_|-| _____
	|_|-| |-| |		|_|-| |-| |
	_ | | |-| _		_ | | |-| _
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 26 ¶
	2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP		2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP
	The (n,n,1) configuration has more than one MR advertising multiple		The (n,n,1) configuration has more than one MR advertising multiple
	global routes. The mobile network is simultaneously associated with		global routes. The mobile network is simultaneously associated with
	multiple HAs and a single MNP is available in the NEMO.		multiple HAs and a single MNP is available in the NEMO.
	The NEMO is multihomed since it has multiple MRs and HAs, but in		The NEMO is multihomed since it has multiple MRs and HAs, but in
	addition the conditions detailed in Section 2.1 may also hold for		addition the conditions detailed in Section 2.1 may also hold for
	each MR. A bi-directional tunnel would then be established between		each MR. A bi-directional tunnel would then be established between
	each pair of Home Address / Care-of Address.		each HoA-CoA pair.
	Regarding MNNs, they are (usually) not multihomed since they would		Regarding MNNs, they are (usually) not multihomed since they would
	configure a single global address from the single MNP available on		configure a single global address from the single MNP available on
	the link they are attached to.		the link they are attached to.
	MR2 AR HA2		MR2 AR HA2
	p _ |		p _ |
	<-_ | |-|_|-| _		<-_ | |-|_|-| _
	_ |-|_|-| _____ | |-|_|		_ |-|_|-| _____ | |-|_|
	|_|-| |-| |-|		|_|-| |-| |-|
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs		2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs
	The (n,n,n) configuration has multiple MRs advertising different		The (n,n,n) configuration has multiple MRs advertising different
	global routes. The mobile network is simultaneously associated with		global routes. The mobile network is simultaneously associated with
	more than one HA and multiple MNPs are available in the NEMO.		more than one HA and multiple MNPs are available in the NEMO.
	The NEMO is multihomed since it has multiple MRs and HAs, but in		The NEMO is multihomed since it has multiple MRs and HAs, but in
	addition the conditions detailed in Section 2.1 may also hold for		addition the conditions detailed in Section 2.1 may also hold for
	each MR. A bi-directional tunnel would then be established between		each MR. A bi-directional tunnel would then be established between
	each pair of Home Address / Care-of Address.		each HoA-CoA pair.
	Regarding MNNs, they are generally multihomed since they would		Regarding MNNs, they are generally multihomed since they would
	configure a global address from each MNP available on the link they		configure a global address from each MNP available on the link they
	are attached to.		are attached to.
	MR2 AR HA2		MR2 AR HA2
	p2 _ |		p2 _ |
	<-_ | |-|_|-| _		<-_ | |-|_|-| _
	_ |-|_|-| _____ | |-|_|		_ |-|_|-| _____ | |-|_|
	|_|-| |-| |-|		|_|-| |-| |-|
	skipping to change at page 14, line 37 ¶		skipping to change at page 14, line 37 ¶
	o Most single ISP cases in above examples.		o Most single ISP cases in above examples.
	z=N: Multihomed mobile networks with multiple MNPs		z=N: Multihomed mobile networks with multiple MNPs
	o Most multiple ISP cases in above examples.		o Most multiple ISP cases in above examples.
	o Example: a car with a prefix taken from home (personal traffic		o Example: a car with a prefix taken from home (personal traffic
	transit on this prefix and is paid by the owner) and one that		transit on this prefix and is paid by the owner) and one that
	belongs to the car manufacturer (maintenance traffic is paid by		belongs to the car manufacturer (maintenance traffic is paid by
	the car-manufacturer). This will typically be a (1,1,n) or a		the car manufacturer). This will typically be a (1,1,n) or a
	(1,n,n,) configuration.		(1,n,n,) configuration.
	Benefits: Preference Settings		Benefits: Preference Settings
	3.2. Prerequisites		3.2. Prerequisites
	In this section, requirements are started in order to comply with the		In this section, requirements are started in order to comply with the
	expected benefits of multihoming as detailed in [6].		expected benefits of multihoming as detailed in [6].
	At least one bi-directional tunnel must be available at any point in		At least one bi-directional tunnel must be available at any point in
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 19 ¶
	or simultaneously (e.g. for load sharing).		or simultaneously (e.g. for load sharing).
	In some cases, it may be necessary to divert packets from a (perhaps		In some cases, it may be necessary to divert packets from a (perhaps
	failed) bi-directional tunnel to an alternative (perhaps newly		failed) bi-directional tunnel to an alternative (perhaps newly
	established) bi-directional tunnel (i.e. for matters of fault		established) bi-directional tunnel (i.e. for matters of fault
	recovery, preferences), or to split traffic between multiple tunnels		recovery, preferences), or to split traffic between multiple tunnels
	(load sharing, load balancing).		(load sharing, load balancing).
	So, depending on the configuration under consideration, the issues		So, depending on the configuration under consideration, the issues
	discussed below may need to be addressed, sometimes dynamically. For		discussed below may need to be addressed, sometimes dynamically. For
	each issue, potential ways to solve the problem are investigated and		each issue, potential ways to solve the problem are investigated.
	an a recommendation is made on which IETF WG(s) should look into
	these issues.
	4.1. Fault Tolerance		4.1. Fault Tolerance
	One of the goals of multihoming is the provision of fault tolerance		One of the goals of multihoming is the provision of fault tolerance
	capabilities. In order to provide such features, a set of tasks need		capabilities. In order to provide such features, a set of tasks need
	to be performed, including: failure detection, alternative available		to be performed, including: failure detection, alternative available
	path exploration, path selection, re-homing of established		path exploration, path selection, re-homing of established
	communications. These are also discussed in [8] and [9] by the Shim6		communications. These are also discussed in [8] and [9] by the Shim6
	WG. In the following sub-sections, we look at these issues in the		WG. In the following sub-sections, we look at these issues in the
	specific context of NEMO, rather than the general Shim6 perspective		specific context of NEMO, rather than the general Shim6 perspective
	skipping to change at page 19, line 7 ¶		skipping to change at page 18, line 51 ¶
	specific issue.		specific issue.
	o For the (n,1,*) cases, there is a single HA, so all the traffic		o For the (n,1,*) cases, there is a single HA, so all the traffic
	from and to the NEMO will flow through it. The available		from and to the NEMO will flow through it. The available
	alternative paths are the different ones between the different MRs		alternative paths are the different ones between the different MRs
	and the HA. The path exploration mechanism needs only to involve		and the HA. The path exploration mechanism needs only to involve
	the HA and the MRs. This is a NEMO/MIPv6 specific issue.		the HA and the MRs. This is a NEMO/MIPv6 specific issue.
	o For the (n,n,*) cases, there are multiple paths between the		o For the (n,n,*) cases, there are multiple paths between the
	different HAs and the different MRs. In this case, alternative		different HAs and the different MRs. In this case, alternative
	paths may be routed completely independently one from each other.		paths may be routed completely independently one from one another.
	An end-to-end path exploration mechanism would be able to discover		An end-to-end path exploration mechanism would be able to discover
	if any of the end-to-end paths is available. The (n,n,1) case,		if any of the end-to-end paths is available. The (n,n,1) case,
	however, seems to be pretty NEMO specific, because of the absence		however, seems to be pretty NEMO specific, because of the absence
	of multiple prefixes. The (n,n,n) case is hybrid, since for those		of multiple prefixes. The (n,n,n) case is hybrid, since for those
	cases that selecting a different prefix result in a change of		cases that selecting a different prefix result in a change of
	path, the Shim6 protocols (such as [9]) may be useful. The other		path, the Shim6 protocols (such as [9]) may be useful. The other
	cases, are NEMO specific.		cases, are NEMO specific.
	Most of the above cases involve the path exploration of tunnels		Most of the above cases involve the path exploration of tunnels
	between HA(s) and MR(s). This is no different from the case of path		between HA(s) and MR(s). This is no different from the case of path
	skipping to change at page 31, line 37 ¶		skipping to change at page 31, line 37 ¶
	configurations under the operation of NEMO Basic Support are		configurations under the operation of NEMO Basic Support are
	analyzed. Security considerations of these multihoming		analyzed. Security considerations of these multihoming
	configurations, should they be different from those that concern NEMO		configurations, should they be different from those that concern NEMO
	Basic Support, must be considered by forthcoming solutions.		Basic Support, must be considered by forthcoming solutions.
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank people who have given valuable		The authors would like to thank people who have given valuable
	comments on various multihoming issues on the mailing list, and also		comments on various multihoming issues on the mailing list, and also
	those who have suggested directions in the 56th - 61st IETF Meetings.		those who have suggested directions in the 56th - 61st IETF Meetings.
	The initial evaluation of NEMO Basic Support is a contribution from		The initial evaluation of NEMO Basic Support on multihoming
	Julien Charbon.		configurations is a contribution from Julien Charbon.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Ernst, T., "Network Mobility Support Goals and Requirements",		[1] Ernst, T., "Network Mobility Support Goals and Requirements",
	draft-ietf-nemo-requirements-05 (work in progress),		draft-ietf-nemo-requirements-05 (work in progress),
	October 2005.		October 2005.
	[2] Manner, J. and M. Kojo, "Mobility Related Terminology",		[2] Manner, J. and M. Kojo, "Mobility Related Terminology",
	skipping to change at page 32, line 31 ¶		skipping to change at page 32, line 31 ¶
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[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.
	10.2. Informative References		10.2. Informative References
	[6] Ernst, T., "Motivations and Scenarios for Using Multiple		[6] Ernst, T., "Motivations and Scenarios for Using Multiple
	Interfaces and Global Addresses",		Interfaces and Global Addresses",
	draft-ietf-monami6-multihoming-motivations-scenarios-00 (work		draft-ietf-monami6-multihoming-motivation-scenario-00 (work in
	in progress), February 2006.		progress), February 2006.
	[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.		[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
	Kuladinithi, "Analysis of Multihoming in Mobile IPv6",		Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
	draft-ietf-monami6-mipv6-analysis-00 (work in progress),		draft-ietf-monami6-mipv6-analysis-00 (work in progress),
	February 2006.		February 2006.
	[8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair		[8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
	Exploration Protocol for IPv6 Multihoming",		Exploration Protocol for IPv6 Multihoming",
	draft-ietf-shim6-failure-detection-03 (work in progress),		draft-ietf-shim6-failure-detection-03 (work in progress),
	December 2005.		December 2005.
	skipping to change at page 34, line 12 ¶		skipping to change at page 34, line 12 ¶
	[23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix		[23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
	Delegation", RFC 3769, June 2004.		Delegation", RFC 3769, June 2004.
	[24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",		[24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
	draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.		draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
	[25] Kniveton, T. and P. Thubert, "Mobile Network Prefix		[25] Kniveton, T. and P. Thubert, "Mobile Network Prefix
	Delegation", draft-ietf-nemo-prefix-delegation-00 (work in		Delegation", draft-ietf-nemo-prefix-delegation-00 (work in
	progress), August 2005.		progress), August 2005.
	[26] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of		[26] Wakikawa, R., "Multiple Care-of Addresses Registration",
	Addresses Registration", draft-wakikawa-mobileip-multiplecoa-05		draft-ietf-monami6-multiplecoa-00 (work in progress),
	(work in progress), February 2006.		June 2006.
	[27] Draves, R., "Default Address Selection for Internet Protocol		[27] Draves, R., "Default Address Selection for Internet Protocol
	version 6 (IPv6)", RFC 3484, February 2003.		version 6 (IPv6)", RFC 3484, February 2003.
	[28] Thubert, P., "Nested Nemo Tree Discovery",		[28] Thubert, P., "Nested Nemo Tree Discovery",
	draft-thubert-tree-discovery-02 (work in progress), July 2005.		draft-thubert-tree-discovery-02 (work in progress), July 2005.
	[29] Kumazawa, M., "Token based Duplicate Network Detection for		[29] Kumazawa, M., "Token based Duplicate Network Detection for
	split mobile network (Token based DND)",		split mobile network (Token based DND)",
	draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.		draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.
	skipping to change at page 38, line 15 ¶		skipping to change at page 38, line 15 ¶
	A.2. Problem-Oriented Approach		A.2. Problem-Oriented Approach
	A third approach is proposed by Pascal Thubert (Cisco System). This		A third approach is proposed by Pascal Thubert (Cisco System). This
	focused on the problems of multihomed mobile networks rather than the		focused on the problems of multihomed mobile networks rather than the
	configuration or ownership. With this approach, there is a set of 4		configuration or ownership. With this approach, there is a set of 4
	categories based on two orthogonal parameters: the number of HAs, and		categories based on two orthogonal parameters: the number of HAs, and
	the number of MNPs advertised. Since the two parameters are		the number of MNPs advertised. Since the two parameters are
	orthogonal, the categories are not mutually exclusive. The four		orthogonal, the categories are not mutually exclusive. The four
	categories are:		categories are:
	o Tarzan: Single HA for Different Care-of Addresses of Same MNP		o Tarzan: Single HA for Different CoAs of Same MNP
	This is the case where one mobile router registers different		This is the case where one MR registers different Care-of
	Care-of Addresses to the same home agent for the same subnet		Addresses to the same HA for the same subnet prefix. This is
	prefix. This is equivalent to the case of y=1, i.e. the (1,1,*)		equivalent to the case of y=1, i.e. the (1,1,*) mobile network.
	mobile network.
	o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP		o JetSet: Multiple HAs for Different CoAs of Same MNP
	This is the case where the mobile router registers different		This is the case where the MR registers different Care-of
	Care-of Addresses to different home agents for the same subnet		Addresses to different HAs for the same subnet prefix. This is
	prefix. This is equivalent to the case of y=n, i.e. the (1,n,*)		equivalent to the case of y=n, i.e. the (1,n,*) mobile network.
	mobile network.
	o Shinkansen: Single MNP Advertised by MR(s)		o Shinkansen: Single MNP Advertised by MR(s)
	This is the case where one MNP is announced by different MRs.		This is the case where one MNP is announced by different MRs.
	This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)		This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)
	mobile network.		mobile network.
	o DoubleBed: Multiple MNPs Advertised by MR(s)		o DoubleBed: Multiple MNPs Advertised by MR(s)
	This is the case where more than one MNPs are announced by the		This is the case where more than one MNPs are announced by the
	skipping to change at page 40, line 22 ¶		skipping to change at page 40, line 22 ¶
	alternate route is provided by another MR connected to the mobile		alternate route is provided by another MR connected to the mobile
	network. We refer to the former case as an alternate route provided		network. We refer to the former case as an alternate route provided
	by an alternate egress interface, and the latter case as an alternate		by an alternate egress interface, and the latter case as an alternate
	route provided by an alternate MR.		route provided by an alternate MR.
	B.2.1. Using Alternate Egress Interface		B.2.1. Using Alternate Egress Interface
	When an egress interface of a MR loses the connection to the global		When an egress interface of a MR loses the connection to the global
	Internet, the MR can make use of its alternate egress interface		Internet, the MR can make use of its alternate egress interface
	should it possess multiple egress interfaces. The most direct way to		should it possess multiple egress interfaces. The most direct way to
	do so is for the mobile router to send a binding update to the home		do so is for the MR to send a binding update to the HA of the failed
	agent of the failed interface using the Care-of Address assigned to		interface using the CoA assigned to the alternate interface in order
	the alternate interface in order to re-establish the bi-directional		to re-establish the bi-directional tunneling using the CoA on the
	tunneling using the Care-of Address on the alternate egress		alternate egress interface. After a successful binding update, the
	interface. After a successful binding update, the MR encapsulates		MR encapsulates outgoing packets through the bi-directional tunnel
	outgoing packets through the bi-directional tunnel using the		using the alternate egress interface.
	alternate egress interface.
	The idea is to use the global address (most likely a Care-of Address)		The idea is to use the global address (most likely a CoA) assigned to
	assigned to an alternate egress interface as the new (back-up)		an alternate egress interface as the new (back-up) CoA of the MR to
	Care-of Address of the mobile router to re-establish the bi-		re-establish the bi-directional tunneling with its HA.
	directional tunneling with its home agent.
	B.2.2. Using Alternate Mobile Router		B.2.2. Using Alternate Mobile Router
	When the MR loses a connection to the global Internet, the MR can		When the MR loses a connection to the global Internet, the MR can
	utilize a route provided by an alternate MR (if one exists) to re-		utilize a route provided by an alternate MR (if one exists) to re-
	establish the bi-directional tunnel with its HA. First, the MR has		establish the bi-directional tunnel with its HA. First, the MR has
	to obtain a Care-of Address from the alternate MR (i.e. attaches		to obtain a CoA from the alternate MR (i.e. attaches itself to the
	itself to the alternate MR). Next, it sends binding update to its HA		alternate MR). Next, it sends binding update to its HA using the CoA
	using the Care-of Address obtained from the alternate MR. From then		obtained from the alternate MR. From then on, the MR can
	on, the MR can encapsulates outgoing packets through the bi-		encapsulates outgoing packets through the bi-directional tunnel using
	directional tunnel using via the alternate MR.		via the alternate MR.
	The idea is to obtain a Care-of Address from the alternate MR and use		The idea is to obtain a CoA from the alternate MR and use this as the
	this as the new (back-up) Care-of Address of the MR to re-establish		new (back-up) CoA of the MR to re-establish the bi-directional
	the bi-directional tunneling with its HA.		tunneling with its HA.
	Note that every packet sent between MNNs and their correspondent		Note that every packet sent between MNNs and their correspondent
	nodes will experience two levels of encapsulation. First level of		nodes will experience two levels of encapsulation. First level of
	tunneling occurs between a MR which the MNN uses as its default		tunneling occurs between a MR which the MNN uses as its default
	router and the MR's HA. The second level of tunneling occurs between		router and the MR's HA. The second level of tunneling occurs between
	the alternate MR and its HA.		the alternate MR and its HA.
	B.3. To Avoid Tunneling Loop		B.3. To Avoid Tunneling Loop
	The method of re-establishing the bi-directional tunnel as described		The method of re-establishing the bi-directional tunnel as described
	skipping to change at page 42, line 13 ¶		skipping to change at page 42, line 13 ¶
	that its link is no longer working.		that its link is no longer working.
	Appendix C. Change Log		Appendix C. Change Log
	o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt		o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
	which is itself a merge of 3 previous drafts		which is itself a merge of 3 previous drafts
	draft-ng-nemo-multihoming-issues-02.txt,		draft-ng-nemo-multihoming-issues-02.txt,
	draft-eun-nemo-multihoming-problem-statement-00.txt, and		draft-eun-nemo-multihoming-problem-statement-00.txt, and
	draft-charbon-nemo-multihoming-evaluation-00.txt		draft-charbon-nemo-multihoming-evaluation-00.txt
			o Changes from draft-ietf-nemo-multihoming-issues-05 to -06:
			* Minor editorial corrections and reference update
	o Changes from draft-ietf-nemo-multihoming-issues-04 to -05:		o Changes from draft-ietf-nemo-multihoming-issues-04 to -05:
	* Addressed Issue #23: modified text in Sect 4.2: "Ingress		* Addressed Issue #23: modified text in Sect 4.2: "Ingress
	Filtering"		Filtering"
	* Re-phrase statements in Sect 4 and 5 where we "... recommend		* Re-phrase statements in Sect 4 and 5 where we "... recommend
	issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to		issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to
	instead suggest that solution to the issue be solicited		instead suggest that solution to the issue be solicited
	elsewhere within the IETF.		elsewhere within the IETF.
	skipping to change at page 45, line 30 ¶		skipping to change at page 45, line 30 ¶
	17 Woomyeon-dong, Seocho-gu		17 Woomyeon-dong, Seocho-gu
	Seoul 137-792		Seoul 137-792
	Korea		Korea
	Phone: +82-2-526-5233		Phone: +82-2-526-5233
	Fax: +82-2-526-5200		Fax: +82-2-526-5200
	Email: euna@kt.co.kr		Email: euna@kt.co.kr
	URI: http://mmlab.snu.ac.kr/~eun/		URI: http://mmlab.snu.ac.kr/~eun/
	Thierry Ernst		Thierry Ernst
	Keio University / WIDE		INRIA
	Jun Murai Lab., Keio University.		INRIA Rocquencourt
	K-square Town Campus, 1488-8 Ogura, Saiwa-Ku		Domaine de Voluceau B.P. 105
	Kawasaki, Kanagawa 212-0054		Le Chesnay, 78153
	Japan		France
	Phone: +81-44-580-1600		Phone: +33-1-39-63-59-30
	Fax: +81-44-580-1437		Fax: +33-1-39-63-54-91
	Email: ernst@sfc.wide.ad.jp		Email: thierry.ernst@inria.fr
	URI: http://www.sfc.wide.ad.jp/~ernst/		URI: http://www.nautilus6.org/~thierry
	Marcelo Bagnulo		Marcelo Bagnulo
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad, 30		Av. Universidad, 30
	Leganes, Madrid 28911		Leganes, Madrid 28911
	Spain		Spain
	Phone: +34 91624 8837		Phone: +34 91624 8837
	Email: marcelo@it.uc3m.es		Email: marcelo@it.uc3m.es
End of changes. 39 change blocks.
	89 lines changed or deleted		84 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/