< draft-farrer-softwire-br-multiendpoints-00.txt		draft-farrer-softwire-br-multiendpoints-01.txt >
	Softwire Working Group I. Farrer		Softwire Working Group I. Farrer
	Internet-Draft Q. Sun		Internet-Draft Q. Sun
	Intended status: Standards Track Deutsche Telekom AG		Intended status: Standards Track Deutsche Telekom AG
	Expires: September 10, 2015 March 9, 2015		Expires: January 7, 2016 July 6, 2015
	Multiple Tunnel Endpoints on Border Router		Multiple BR Tunnel Endpoint Addresses
	draft-farrer-softwire-br-multiendpoints-00		draft-farrer-softwire-br-multiendpoints-01
	Abstract		Abstract
	This document defines a mechanism to enable an IPv4-over-IPv6		As 'softwire' based approaches for providing IPv4 services to IPv6
	Softwire Border Router to support multiple tunnel endpoint on one BR		networks
	instance. This feature can be used to group users based on IPv6
	tunnel endpoint addresses and achieve high availability.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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 39 ¶		skipping to change at page 1, line 37 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 10, 2015.		This Internet-Draft will expire on January 7, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Changes to BR's Behavior . . . . . . . . . . . . . . . . . . 3		2. Analysis of BR Provisioning Approaches . . . . . . . . . . . 3
	3. Changes to Initiator's Behavior . . . . . . . . . . . . . . . 4		2.1. Single BR Tunnel Endpoint Approach . . . . . . . . . . . 3
	4. Operational Considerations . . . . . . . . . . . . . . . . . 4		2.2. Per-client Unique BR Tunnel Endpoint Address Approach . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		2.3. A Mix of Both . . . . . . . . . . . . . . . . . . . . . . 3
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		3. Changes to BR's Behavior . . . . . . . . . . . . . . . . . . 4
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		4. Changes to Initiator's Behavior . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Operational Considerations . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
			9.1. Normative References . . . . . . . . . . . . . . . . . . 6
			9.2. Informative References . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Softwire WG has developed a number of IPv4-over-IPv6 transition		The Softwire WG has developed a number of IPv4-over-IPv6 transition
	mechanisms that utilize a hub-and-spoke network architecture.		mechanisms based on a hub-and-spoke network architecture, with the
	Although the schema for configuring an BR varies according to the		Border Router (BR) functioning as the hub. Although the schema for
	mechanism being implemented (using either a per-subscriber rule or an		configuring a BR varies according to the mechanism being implemented
	algorithmic mapping rule), in their current shape all mechanisms only		(using either a per-subscriber rule or an algorithmic mapping rule),
	allow for a single IPv6 address to be used as the BR's IPv6 tunnel		vendor's implementations differ in their approach to the provisioning
	address. This address is provisioned to all Softwire Initiators to		of tunnel endpoints on the BR. In some implementations, a single
	use as the destination address for their IPv4-in-IPv6 tunneled		address must be used for terminating all clients traffic, some
	traffic and is used by the BR as the source address for encapsulated		implementations require every client to use a different tunnel
	traffic being sent to Softwire initiators.		endpoint and some employ a 'hybrid' approach, allowing for the
			clients to have unique BR addresses, and other clients to be
			arbrarily grouped with multiple clients using the same BR tunnel
			endpoint address.
	The inherent limitation in having only a single IPv6 tunnel endpoint		From an operator's standpoint, this difference creates a provisioning
	address available for the BR is that it is not possbile to		problem: The values of the parameters with which softwire initiators
	differentiate client's tunneled traffic based on BR's address in the		need to be provisioned vary depending on the BR's tunnel endpoint
	encapsulating IPv6 packet. However, by implementing multiple IPv6		provisioning approach. In a multi-vendor environment, this becomes
	tunnel endpoint addresses, the BR can support different classes of		unmanagable and significantly complicates migration of users and geo-
	users, grouped by their tunnel endpoint address. Grouping clients		redundancy between BR's from different vendors.
	based on a common tunnel endpoint address makes it simple for
	intermediate IPv6 network elements to identify client's traffic group		This document proposes that the 'hybrid' approach for BR tunnel
	by examining the encapsulating IPv6 header, e.g. so that traffic		endpoints offers the most flexibility and should be the model
	forwarding policies can be applied.		implemented in softwire concentrators.
			2. Analysis of BR Provisioning Approaches
			2.1. Single BR Tunnel Endpoint Approach
			In this implementation approach, only a single IPv6 address is used
			as the BR's IPv6 tunnel address. This address is provisioned to all
			softwire initiators to use as the destination for their IPv4-in-IPv6
			tunneled traffic, and is used by the BR as the source address for
			encapsulated traffic being sent to Softwire initiators.
			The obvious advantage is that all clients can be provisioned with the
			same address for the BR. In smaller scale deployments, this may be
			sufficient for an operator's needs. In larger scale deployments,
			this schema makes it difficult to design and plan for the grouping of
			users and geographical failover.
			Only supporting a single IPv6 BR tunnel endpoint address available
			has another limitation: it is not possbile to differentiate client's
			tunneled traffic based on BR's address in the encapsulating IPv6
			packet.
			2.2. Per-client Unique BR Tunnel Endpoint Address Approach
			In this implementation approach, each client is provisioned with a
			unique /128 address to use as the destination address for their
			tunneled traffic. The BR is configured with exactly as many unique
			tunnel endpoint addresses as there are softwire initiators.
			The main disadvantage with this approach is that it places an
			additional provisioning overhead on the operator to ensure that each
			client has a unique BR address. When provisioning lw4o6 using DHCPv6
			as described in [I-D.ietf-softwire-map-dhcp], maintaining per-client
			DHCPv6 entries is a necessary provisioning overhead. But when
			dynamic provisionig of lw4o6 clients is used [RFC7341], per-client
			entries in the provisioning system are no longer required, as the
			IPv4 addresses for clients are taken from an address pool. However,
			if each client still needs to be provisioned with a unique tunnel
			endpoint address associated with the IPv4 address it has been
			allocated, then the provisioning model becomes complex and
			potentially unworkable.
			2.3. A Mix of Both
			This document proposes that a BR SHOULD support per-client IPv6
			tunnel endpoints, but not mandate that these addresses are unique.
			E.g., the endpoints can be all the same, or unique, or any
			combination of unique and shared.
			By implementing multiple IPv6 tunnel endpoint addresses in this
			'mixed' mode, the BR can support different classes of users, grouped
			through their tunnel endpoint address. Grouping clients based on a
			common tunnel endpoint address makes it simple for intermediate IPv6
			network elements to identify client's traffic group by examining the
			encapsulating IPv6 header, e.g. so that traffic forwarding policies
			can be applied.
	It also allows for flexible, anycast based geographical resilience		It also allows for flexible, anycast based geographical resilience
	models where each BR supports a primary group of users and a		models where each BR supports a primary group of users and a
	secondary group, differentiated by the tunnel endpoint address.		secondary group, differentiated by the tunnel endpoint address.
	Traffic is flexibly routed through auto-routing protocols and Equal-		Traffic is flexibly routed through auto-routing protocols and Equal-
	Cost Multipath (ECMP).		Cost Multipath (ECMP).
	This document describes a method that enables one Border Router to		This document describes a method that enables one Border Router to
	serve multiple groups of clients. The BR's mapping/binding table		serve in such a mix mode. The BR's mapping/binding table must hold
	must hold an additional "BR source IPv6 address" field for each		an additional "BR source IPv6 address" field for each Softwire
	Softwire Initiator it is configured to support.		Initiator it is configured to support. The IPv6 addresses of that
			field can be all the same or not, based on the operational
			requirements.
	This mechanism can be applied to lw4over6		This mechanism can be applied to lw4over6
	[I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map] and MAP-T		[I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map] and MAP-T
	[I-D.ietf-softwire-map-t].		[I-D.ietf-softwire-map-t].
	DISCUSSION - Is this necessary for MAP BRs, or can this already be		DISCUSSION - Is this necessary for MAP BRs, or can this already be
	supported?		supported?
	2. Changes to BR's Behavior		3. Changes to BR's Behavior
	Existing BRs implementing lw4o6, MAP-E or MAP-T are provisioned with		Existing BRs implementing lw4o6, MAP-E or MAP-T are provisioned with
	a set of rules defining packet processing behaviour. The rule/		a set of rules defining packet processing behaviour. The rule/
	binding table on the Border Router only contains the mapping between		binding table on the Border Router only contains the mapping between
	the IPv6 and IPv4 address and source ports for the Softwire		the IPv6 and IPv4 address and source ports for the Softwire
	Initiators. In this mechanism, the rule/binding table is extended to		Initiators. In this mechanism, the rule/binding table is extended to
	include the IPv6 tunnel address(es) configured on the BR as another		include the IPv6 tunnel address(es) configured on the BR as another
	field. The Softwire Initiators' IPv6-IPv4 mapping rules are then		field. The Softwire Initiators' IPv6-IPv4 mapping rules are then
	linked to the related BR's IPv6 tunnel addresses. As such, it is		linked to the related BR's IPv6 tunnel addresses. As such, it is
	possible for one BR to serve multiple groups of Softwire Initiators,		possible for one BR to serve multiple groups of Softwire Initiators,
	skipping to change at page 3, line 45 ¶		skipping to change at page 5, line 12 ¶
	made, the encapsulated/translated IPv4 packet is then verified as		made, the encapsulated/translated IPv4 packet is then verified as
	documented in related Softwire mechanisms.		documented in related Softwire mechanisms.
	When the BR receives a packet from the IPv4 Internet, it looks up for		When the BR receives a packet from the IPv4 Internet, it looks up for
	the matching entry using the destination IPv4 address and port		the matching entry using the destination IPv4 address and port
	number. The BR MUST also retrieve the associated BR's IPv6 address		number. The BR MUST also retrieve the associated BR's IPv6 address
	to use for the encapsulating packet's source IPv6 address. Depending		to use for the encapsulating packet's source IPv6 address. Depending
	on the implemented mechanism, the mapping rule for constructing the		on the implemented mechanism, the mapping rule for constructing the
	destination IPv6 address will need to be retrieved as normal.		destination IPv6 address will need to be retrieved as normal.
	The rest of encapsulation/decapsulation/translation process is		The rest of encapsulation/decapsulation/translation process is inline
	aligned with the related mechanisms.		with the related mechanisms.
	3. Changes to Initiator's Behavior		4. Changes to Initiator's Behavior
	The Softwire Initiator's behavior is identical to that in the related		The Softwire Initiator's behavior is identical to that in the related
	mechanisms. That is, when it receives an IPv4-in-IPv6 packet it		mechanisms. That is, when it receives an IPv4-in-IPv6 packet it
	checks the source and destination addresses against its		checks the source and destination addresses against its
	configuration. The source address of the packet MUST match the BR's		configuration. The source address of the packet MUST match the BR's
	tunnel endpoint address configured on the client.		tunnel endpoint address configured on the client.
	4. Operational Considerations		5. Operational Considerations
	Border Routers need to be provisioned with multiple sets of tunnel		Border Routers need to be provisioned with multiple sets of tunnel
	endpoint IPv6 addresses, IPv4-IPv6 mapping rules for Softwire		endpoint IPv6 addresses, IPv4-IPv6 mapping rules for Softwire
	Initiators and routable IPv4 prefixes. The provisioning mechanisms		Initiators and routable IPv4 prefixes. The provisioning mechanisms
	could include NETCONF, TR69 or out-of-band static configuration.		could include NETCONF, TR-69 or out-of-band static configuration.
	This mechanism is out of scope for this document.		This mechanism is out of scope for this document.
	BRs implementing this mechanism can be deployed using IPv6 anycast to		BRs implementing this mechanism can be deployed using IPv6 anycast to
	achieve high availability. Since multiple IPv6 anycast addresses can		achieve high availability. Since multiple IPv6 anycast addresses can
	be configured on the BR as tunnel endpoint addresses, a BR is able to		be configured on the BR as tunnel endpoint addresses, a BR is able to
	serve one primary domain while serving other domains as backup. The		serve one primary domain while serving other domains as backup. The
	BR advertises the IPv6 anycast prefix(es), as well as the routable		BR advertises the IPv6 anycast prefix(es), as well as the routable
	IPv4 prefix(es). ECMP can be used to leverage for stateless load-		IPv4 prefix(es). ECMP can be used to leverage for stateless load-
	balancing across multiple BRs.		balancing across multiple BRs.
	skipping to change at page 4, line 42 ¶		skipping to change at page 5, line 52 ¶
	has the lowest routing metric to the ingress point in the network.		has the lowest routing metric to the ingress point in the network.
	This may results in different paths for egress and ingress traffic.		This may results in different paths for egress and ingress traffic.
	Whilst stateless and per-subscriber state softwire mechansims		Whilst stateless and per-subscriber state softwire mechansims
	(described in [RFC6269]) don't require the ingress/egress traffic		(described in [RFC6269]) don't require the ingress/egress traffic
	paths to be symmetrical, it may be desirable for an operator to		paths to be symmetrical, it may be desirable for an operator to
	engineer this way for effective capacity planning. The exact		engineer this way for effective capacity planning. The exact
	mechanism for achieving this will be dependant on the network's		mechanism for achieving this will be dependant on the network's
	topology and how the operator is utilizes equal-cost multipath based		topology and how the operator is utilizes equal-cost multipath based
	load balancing.		load balancing.
	NOTE: One possible other consideration is that as there is an		NOTE: Another possible consideration is that as there is an
	additional lookup action that needs to be carried out for packets at		additional lookup action that needs to be carried out for packets at
	the BR, there may be a packet processing overhead.		the BR, there may be a packet processing overhead.
	5. Security Considerations		6. Security Considerations
	TBD		TBD
	6. IANA Considerations		7. IANA Considerations
	This document does not include an IANA request.		This document does not include an IANA request.
	7. Acknowledgements		8. Acknowledgements
	The authors would like to thank Madhusuhdan Vadde for contributions		The authors would like to thank Madhusuhdan Vadde for contributions
	to this work.		to this work.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, December 1998.		IPv6 Specification", RFC 2473, December 1998.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-softwire-lw4over6]		[I-D.ietf-softwire-lw4over6]
	Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and		Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
	I. Farrer, "Lightweight 4over6: An Extension to the DS-		I. Farrer, "Lightweight 4over6: An Extension to the DS-
	Lite Architecture", draft-ietf-softwire-lw4over6-13 (work		Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
	in progress), November 2014.		in progress), November 2014.
	[I-D.ietf-softwire-map]		[I-D.ietf-softwire-map]
	Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,		Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Murakami, T., and T. Taylor, "Mapping of Address and Port		Murakami, T., and T. Taylor, "Mapping of Address and Port
	skipping to change at page 6, line 9 ¶		skipping to change at page 7, line 15 ¶
	[I-D.ietf-softwire-map-t]		[I-D.ietf-softwire-map-t]
	Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and		Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
	T. Murakami, "Mapping of Address and Port using		T. Murakami, "Mapping of Address and Port using
	Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work		Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work
	in progress), December 2014.		in progress), December 2014.
	[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.		[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
	Roberts, "Issues with IP Address Sharing", RFC 6269, June		Roberts, "Issues with IP Address Sharing", RFC 6269, June
	2011.		2011.
			[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
			Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC
			7341, August 2014.
	Authors' Addresses		Authors' Addresses
	Ian Farrer		Ian Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	CTO-ATI,Landgrabenweg 151		CTO-ATI,Landgrabenweg 151
	Bonn, NRW 53227		Bonn, NRW 53227
	Germany		Germany
	Email: ian.farrer@telekom.de		Email: ian.farrer@telekom.de
End of changes. 21 change blocks.
	53 lines changed or deleted		120 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/