< draft-ietf-dots-multihoming-08.txt		draft-ietf-dots-multihoming-09.txt >
	Network Working Group M. Boucadair		Network Working Group M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy		Intended status: Informational T. Reddy
	Expires: 28 April 2022 McAfee		Expires: 5 June 2022 McAfee
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	25 October 2021		2 December 2021
	Multi-homing Deployment Considerations for Distributed-Denial-of-Service		Multi-homing Deployment Considerations for Distributed-Denial-of-Service
	Open Threat Signaling (DOTS)		Open Threat Signaling (DOTS)
	draft-ietf-dots-multihoming-08		draft-ietf-dots-multihoming-09
	Abstract		Abstract
	This document discusses multi-homing considerations for Distributed-		This document discusses multi-homing considerations for Distributed-
	Denial-of-Service Open Threat Signaling (DOTS). The goal is to		Denial-of-Service Open Threat Signaling (DOTS). The goal is to
	provide some guidance for DOTS clients/gateways when multihomed.		provide some guidance for DOTS clients/gateways when multihomed.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on 28 April 2022.		This Internet-Draft will expire on 5 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 5		4. Multi-Homing Scenarios . . . . . . . . . . . . . . . . . . . 5
	4.1. Multi-Homed Residential Single CPE . . . . . . . . . . . 5		4.1. Multi-Homed Residential Single CPE . . . . . . . . . . . 5
	4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream		4.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream		4.3. Multi-homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7		4.4. Multi-homed Enterprise with the Same ISP . . . . . . . . 7
	5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 7		5. DOTS Multi-homing Deployment Considerations . . . . . . . . . 8
	5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8		5.1. Residential CPE . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream		5.2. Multi-Homed Enterprise: Single CPE, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream
	ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12		ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13		5.4. Multi-Homed Enterprise: Single ISP . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In many deployments, it may not be possible for a network to		In many deployments, it may not be possible for a network to
	determine the cause of a distributed Denial-of-Service (DoS) attack		determine the cause of a distributed Denial-of-Service (DoS) attack
	[RFC4732]. Rather, the network may just realize that some resources		[RFC4732]. Rather, the network may just realize that some resources
	appear to be under attack. To help with such situations, the IETF		appear to be under attack. To help with such situations, the IETF
	has specified the DDoS Open Threat Signaling (DOTS) architecture		has specified the DDoS Open Threat Signaling (DOTS) architecture
	[RFC8811], where a DOTS client can inform an upstream DOTS server		[RFC8811], where a DOTS client can inform an upstream DOTS server
	that its network is under a potential attack and that appropriate		that its network is under a potential attack and that appropriate
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	IP indifferently refers to IPv4 or IPv6.		IP indifferently refers to IPv4 or IPv6.
	4. Multi-Homing Scenarios		4. Multi-Homing Scenarios
	This section describes some multi-homing scenarios that are relevant		This section describes some multi-homing scenarios that are relevant
	to DOTS. In the following subsections, only the connections of		to DOTS. In the following subsections, only the connections of
	border routers are shown; internal network topologies are not		border routers are shown; internal network topologies are not
	elaborated.		elaborated.
			A multihomed network may enable DOTS for all or a subset of its
			upstream interconnection links. In such a case, DOTS servers can be
			explicitly configured or dynamically discovered by a DOTS client
			using means such as those discussed in [RFC8973]. These DOTS servers
			can be owned by the upstream provider, managed by a third-party
			(e.g., mitigation service provider), or a combination thereof.
			If a DOTS server is explicitly configured, it is assumed that an
			interface is also provided to bind the DOTS service to an
			interconnection link. If no interface is provided, this means that
			the DOTS server can be reached via any active interface.
	This section distinguishes between residential CPEs vs. enterprise		This section distinguishes between residential CPEs vs. enterprise
	CPEs because PI addresses may be used for enterprises while this is		CPEs because PI addresses may be used for enterprises while this is
	not the current practice for residential CPEs.		not the current practice for residential CPEs.
			In the following subsections, all or a subset of interconnection
			links are associated with DOTS servers.
	4.1. Multi-Homed Residential Single CPE		4.1. Multi-Homed Residential Single CPE
	The scenario shown in Figure 2 is characterized as follows:		The scenario shown in Figure 2 is characterized as follows:
	* The home network is connected to the Internet using one single		* The home network is connected to the Internet using one single
	CPE.		CPE.
	* The CPE is connected to multiple provisioning domains (i.e., both		* The CPE is connected to multiple provisioning domains (i.e., both
	fixed and mobile networks). Provisioning domain (PvD) is		fixed and mobile networks). Provisioning domain (PvD) is
	explained in [RFC7556].		explained in [RFC7556].
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 39 ¶
	These deployment schemes are further discussed in the following		These deployment schemes are further discussed in the following
	subsections.		subsections.
	5.1. Residential CPE		5.1. Residential CPE
	Figure 5 depicts DOTS sessions that need to be established between a		Figure 5 depicts DOTS sessions that need to be established between a
	DOTS client (C) and two DOTS servers (S1, S2) within the context of		DOTS client (C) and two DOTS servers (S1, S2) within the context of
	the scenario described in Section 4.1.		the scenario described in Section 4.1.
	For each provisioning domain, the DOTS client MUST resolve the DOTS		For each provisioning domain, the DOTS client MUST resolve the DOTS
	server's name provided by a provisioning domain ([RFC8973]) using the		server's name provided by a provisioning domain [RFC8973] using the
	DNS servers learned from the respective provisioning domain.		DNS servers learned from the respective provisioning domain (or the
	IPv6-capable DOTS clients MUST use the source address selection		DNS servers associated with the interface(s) for which a DOTS server
	algorithm defined in [RFC6724] to select the candidate source		was explicitly configured). IPv6-capable DOTS clients MUST use the
	addresses to contact each of these DOTS servers. DOTS sessions MUST		source address selection algorithm defined in [RFC6724] to select the
	be established and MUST be maintained with each of the DOTS servers		candidate source addresses to contact each of these DOTS servers.
	because the mitigation scope of each of these servers is restricted.		DOTS sessions MUST be established and MUST be maintained with each of
	The DOTS client SHOULD use the certificate provisioned by a		the DOTS servers because the mitigation scope of each of these
	provisioning domain to authenticate itself to the DOTS server(s)		servers is restricted. The DOTS client SHOULD use the certificate
	provided by the same provisioning domain.		provisioned by a provisioning domain to authenticate itself to the
			DOTS server(s) provided by the same provisioning domain.
	When conveying a mitigation request to protect the attack target(s),		When conveying a mitigation request to protect the attack target(s),
	the DOTS client MUST select an available DOTS server whose network		the DOTS client MUST select an available DOTS server whose network
	has assigned the IP prefixes from which target prefixes/addresses are		has assigned the IP prefixes from which target prefixes/addresses are
	derived. This implies that if no appropriate DOTS server is found,		derived. This implies that if no appropriate DOTS server is found,
	the DOTS client MUST NOT send the mitigation request to any other		the DOTS client MUST NOT send the mitigation request to any other
	available DOTS server.		available DOTS server.
	For example, a mitigation request to protect target resources bound		For example, a mitigation request to protect target resources bound
	to a PA IP address/prefix cannot be satisfied by a provisioning		to a PA IP address/prefix cannot be satisfied by a provisioning
	domain other than the one that owns those addresses/prefixes.		domain other than the one that owns those addresses/prefixes.
	Consequently, if a CPE detects a DDoS attack that spreads over all		Consequently, if a CPE detects a DDoS attack that spreads over all
	its network attachments, it MUST contact both DOTS servers for		its network attachments, it MUST contact all DOTS servers for
	mitigation purposes.		mitigation purposes.
	The DOTS client MUST be able to associate a DOTS server with each		The DOTS client MUST be able to associate a DOTS server with each
	provisioning domain. For example, if the DOTS client is provisioned		provisioning domain. For example, if the DOTS client is provisioned
	with S1 using DHCP when attaching to a first network and with S2		with S1 using DHCP when attaching to a first network and with S2
	using Protocol Configuration Option (PCO) [TS.24008] when attaching		using Protocol Configuration Option (PCO) [TS.24008] when attaching
	to a second network, the DOTS client must record the interface from		to a second network, the DOTS client must record the interface from
	which a DOTS server was provisioned. DOTS signaling session to a		which a DOTS server was provisioned. DOTS signaling session to a
	given DOTS server must be established using the interface from which		given DOTS server must be established using the interface from which
	the DOTS server was provisioned.		the DOTS server was provisioned. If a DOTS server is explicitly
			configured, DOTS signaling with that server must be established via
			the interfaces that are indicated in the explicit configuration or
			via any active interface if no interface is configured.
	+--+		+--+
	----------|S1|		----------|S1|
	/ +--+		/ +--+
	/ DOTS Server Domain #1		/ DOTS Server Domain #1
	/		/
	+---+/		+---+/
	| C |		| C |
	+---+\		+---+\
	\		\
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 18 ¶
	established with a DOTS gateway, which is enabled within the context		established with a DOTS gateway, which is enabled within the context
	of the scenario described in Section 4.2. This deployment is		of the scenario described in Section 4.2. This deployment is
	characterized as follows:		characterized as follows:
	* One of more DOTS clients are enabled in hosts located in the		* One of more DOTS clients are enabled in hosts located in the
	internal network.		internal network.
	* A DOTS gateway is enabled to aggregate and then relay the requests		* A DOTS gateway is enabled to aggregate and then relay the requests
	towards upstream DOTS servers.		towards upstream DOTS servers.
	When PA addresses/prefixes are in use, the same considerations
	discussed in Section 5.1 need to be followed by the DOTS gateway to
	contact its DOTS server(s). The DOTS gateways can be reachable from
	DOTS clients by using an unicast address or an anycast address.
	Nevertheless, when PI addresses/prefixes are assigned, the DOTS
	gateway MUST send mitigation requests to all its DOTS servers.
	Otherwise, the attack traffic may still be delivered via the ISP
	which hasn't received the mitigation request.
	+--+		+--+
	----------|S1|		----------|S1|
	+---+ / +--+		+---+ / +--+
	| C1|----+ / DOTS Server Domain #1		| C1|----+ / DOTS Server Domain #1
	+---+ | /		+---+ | /
	+---+ +-+-+/		+---+ +-+-+/
	| C3|------| G |		| C3|------| G |
	+---+ +-+-+\		+---+ +-+-+\
	+---+ | \		+---+ | \
	| C2|----+ \		| C2|----+ \
	+---+ \ +--+		+---+ \ +--+
	----------|S2|		----------|S2|
	+--+		+--+
	DOTS Server Domain #2		DOTS Server Domain #2
	Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple		Figure 6: Multiple DOTS Clients, Single DOTS Gateway, Multiple
	DOTS Servers		DOTS Servers
			When PA addresses/prefixes are in use, the same considerations
			discussed in Section 5.1 need to be followed by the DOTS gateway to
			contact its DOTS server(s). The DOTS gateways can be reachable from
			DOTS clients by using an unicast address or an anycast address.
			Nevertheless, when PI addresses/prefixes are assigned, the DOTS
			gateway MUST send mitigation requests to all its DOTS servers.
			Otherwise, the attack traffic may still be delivered via the ISP
			which hasn't received the mitigation request.
	An alternate deployment model is depicted in Figure 7. This		An alternate deployment model is depicted in Figure 7. This
	deployment assumes that:		deployment assumes that:
	* One or more DOTS clients are enabled in hosts located in the		* One or more DOTS clients are enabled in hosts located in the
	internal network. These DOTS clients may use [RFC8973] to		internal network. These DOTS clients may use [RFC8973] to
	discover their DOTS server(s).		discover their DOTS server(s).
	* These DOTS clients communicate directly with upstream DOTS		* These DOTS clients communicate directly with upstream DOTS
	servers.		servers.
	If PI addresses/prefixes are in use, the DOTS client MUST send a
	mitigation request to all the DOTS servers. The use of anycast
	addresses to reach the DOTS servers is NOT RECOMMENDED.
	If PA addresses/prefixes are used, the same considerations discussed
	in Section 5.1 need to be followed by the DOTS clients. Because DOTS
	clients are not embedded in the CPE and multiple addreses/prefixes
	may not be assigned to the DOTS client (typically in an IPv4
	context), some issues may arise in how to steer traffic towards the
	appropriate DOTS server by using the appropriate source IP address.
	These complications discussed in [RFC4116] are not specific to DOTS.
	..........		..........
	. +--+ .		. +--+ .
	+--------|C1|--------+		+--------|C1|--------+
	| . +--+ . |		| . +--+ . |
	| . . |		| . . |
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	|S2|------|C3|------|S1|		|S2|------|C3|------|S1|
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	| . . |		| . . |
	| . +--+ . |		| . +--+ . |
	+--------|C2|--------+		+--------|C2|--------+
	. +--+ .		. +--+ .
	..........		..........
	DOTS Client		DOTS Client
	Domain		Domain
	Figure 7: Multiple DOTS Clients, Multiple DOTS Servers		Figure 7: Multiple DOTS Clients, Multiple DOTS Servers
			If PI addresses/prefixes are in use, the DOTS client MUST send a
			mitigation request to all the DOTS servers. The use of anycast
			addresses to reach the DOTS servers is NOT RECOMMENDED. If anycast
			addresses are used to reach multiple DOTS servers, the CPE may not be
			able to select the appropriate provisioning domain to which the
			mitigation request should be forwarded. As a consequence, the
			request may not be forwarded to the appropriate DOTS server.
			If PA addresses/prefixes are used, the same considerations discussed
			in Section 5.1 need to be followed by the DOTS clients. Because DOTS
			clients are not embedded in the CPE and multiple addreses/prefixes
			may not be assigned to the DOTS client (typically in an IPv4
			context), some issues may arise in how to steer traffic towards the
			appropriate DOTS server by using the appropriate source IP address.
			These complications discussed in [RFC4116] are not specific to DOTS.
	Another deployment approach is to enable many DOTS clients; each of		Another deployment approach is to enable many DOTS clients; each of
	them is responsible for handling communications with a specific DOTS		them is responsible for handling communications with a specific DOTS
	server (see Figure 8).		server (see Figure 8).
	..........		..........
	. +--+ .		. +--+ .
	+--------|C1| .		+--------|C1| .
	| . +--+ .		| . +--+ .
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	|S2| . |C2|------|S1|		|S2| . |C2|------|S1|
	+--+ . +--+ . +--+		+--+ . +--+ . +--+
	..........		..........
	DOTS Client		DOTS Client
	Domain		Domain
	Figure 8: Single Homed DOTS Clients		Figure 8: Single Homed DOTS Clients
	Each DOTS client SHOULD be provided with policies (e.g., a prefix		For both deployments depicted in Figures 7 and 8, each DOTS client
	filter that will be against DDoS detection alarms) that will trigger		SHOULD be provided with policies (e.g., a prefix filter that will be
	DOTS communications with the DOTS servers. Such policies will help		against DDoS detection alarms) that will trigger DOTS communications
	the DOTS client to select the appropriate destination DOTS server.		with the DOTS servers. Such policies will help the DOTS client to
			select the appropriate destination DOTS server.
	The CPE MUST select the appropriate source IP address when forwarding		The CPE MUST select the appropriate source IP address when forwarding
	DOTS messages received from an internal DOTS client. If anycast		DOTS messages received from an internal DOTS client.
	addresses are used to reach multiple DOTS servers, the CPE may not be
	able to select the appropriate provisioning domain to which the
	mitigation request should be forwarded. As a consequence, the
	request may not be forwarded to the appropriate DOTS server.
	5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs		5.3. Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream ISPs
	The deployments depicted in Figures 7 and 8 also apply to the		The deployments depicted in Figures 7 and 8 also apply to the
	scenario described in Section 4.3. One specific problem for this		scenario described in Section 4.3. One specific problem for this
	scenario is to select the appropriate exit router when contacting a		scenario is to select the appropriate exit router when contacting a
	given DOTS server.		given DOTS server.
	An alternative deployment scheme is shown in Figure 9:		An alternative deployment scheme is shown in Figure 9:
	* DOTS clients are enabled in hosts located in the internal network.		* DOTS clients are enabled in hosts located in the internal network.
	* A DOTS gateway is enabled in each CPE (rtr1, rtr2).		* A DOTS gateway is enabled in each CPE (rtr1, rtr2).
	* Each of these DOTS gateways communicates with the DOTS server of		* Each of these DOTS gateways communicates with the DOTS server of
	the provisioning domain.		the provisioning domain.
			+---+
			+------------| C1|----+
			| +---+ |
			+--+ +-+-+ +---+ +-+-+ +--+
			|S2|------|G2 |------| C3|------|G1 |------|S1|
			+--+ +-+-+ +---+ +-+-+ +--+
			| +---+ |
			+------------| C2|----+
			+---+
			Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple
			DOTS Servers
	When PI addresses/prefixes are used, DOTS clients MUST contact all		When PI addresses/prefixes are used, DOTS clients MUST contact all
	the DOTS gateways to send a DOTS message. DOTS gateways will then		the DOTS gateways to send a DOTS message. DOTS gateways will then
	relay the request to the DOTS server. The use of anycast addresses		relay the request to the DOTS servers. Note that anycast addresses
	to establish DOTS sessions between DOTS clients and DOTS gateways is		cannot be used to establish DOTS sessions between DOTS clients and
	not an option.		DOTS gateways because only one DOTS gateway will receive the
			mitigation request.
	When PA addresses/prefixes are used, but no filter rules are provided		When PA addresses/prefixes are used, but no filter rules are provided
	to DOTS clients, the latter MUST contact all DOTS gateways		to DOTS clients, the latter MUST contact all DOTS gateways
	simultaneously to send a DOTS message. Upon receipt of a request by		simultaneously to send a DOTS message. Upon receipt of a request by
	a DOTS gateway, it MUST check whether the request is to be forwarded		a DOTS gateway, it MUST check whether the request is to be forwarded
	upstream (if the target IP prefix is managed by the upstream server)		upstream (if the target IP prefix is managed by the upstream server)
	or rejected.		or rejected.
	When PA addresses/prefixes are used, but specific filter rules are		When PA addresses/prefixes are used, but specific filter rules are
	provided to DOTS clients using some means that are out of scope of		provided to DOTS clients using some means that are out of scope of
	this document, the clients MUST select the appropriate DOTS gateway		this document, the clients MUST select the appropriate DOTS gateway
	to reach. The use of anycast addresses is NOT RECOMMENDED to reach		to reach. The use of anycast addresses is NOT RECOMMENDED to reach
	DOTS gateways.		DOTS gateways.
	+---+
	+------------| C1|----+
	| +---+ |
	+--+ +-+-+ +---+ +-+-+ +--+
	|S2|------|G2 |------| C3|------|G1 |------|S1|
	+--+ +-+-+ +---+ +-+-+ +--+
	| +---+ |
	+------------| C2|----+
	+---+
	Figure 9: Multiple DOTS Clients, Multiple DOTS Gateways, Multiple
	DOTS Servers
	5.4. Multi-Homed Enterprise: Single ISP		5.4. Multi-Homed Enterprise: Single ISP
	The key difference of the scenario described in Section 4.4 compared		The key difference of the scenario described in Section 4.4 compared
	to the other scenarios is that multi-homing is provided by the same		to the other scenarios is that multi-homing is provided by the same
	ISP. Concretely, that ISP can decide to provision the enterprise		ISP. Concretely, that ISP can decide to provision the enterprise
	network with:		network with:
	* The same DOTS server for all network attachments.		* The same DOTS server for all network attachments.
	* Distinct DOTS servers for each network attachment. These DOTS		* Distinct DOTS servers for each network attachment. These DOTS
End of changes. 22 change blocks.
	70 lines changed or deleted		91 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/