< draft-farrer-softwire-lw4o6-deterministic-arch-00.txt		draft-farrer-softwire-lw4o6-deterministic-arch-01.txt >
	Network Working Group I. Farrer		Network Working Group I. Farrer
	Internet-Draft Deutsche Telekom AG		Internet-Draft Deutsche Telekom AG
	Intended status: Informational A. Durand		Intended status: Informational A. Durand
	Expires: February 1, 2013 Juniper Networks		Expires: April 25, 2013 Juniper Networks
	July 31, 2012		October 22, 2012
	lw4over6 Deterministic Architecture		lw4over6 Deterministic Architecture
	draft-farrer-softwire-lw4o6-deterministic-arch-00		draft-farrer-softwire-lw4o6-deterministic-arch-01
	Abstract		Abstract
	This memo provides an operational deterministic architecture for the		This memo describes an architecture for implementing Lightweight
	deployment of Lightweight 4over6		4over6 (lw4o6) in a scalable and resilient manner. This is achieved
	[I-D.cui-softwire-b4-translated-ds-lite] offering scalability and		using characteristics which are inherent to lw4o6 and dynamic IP
	high-availability whilst preserving the per-flow stateless nature of		routing protocols.
	the solution.
	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 41 ¶		skipping to change at page 1, line 40 ¶
	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 February 1, 2013.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 20 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Deterministic Architecture . . . . . . . . . . . . . . . . . . 3		2. Deterministic Architecture . . . . . . . . . . . . . . . . . . 3
	2.1. Distribution of the Subscriber Population . . . . . . . . . 3		2.1. Distribution of the Subscriber Population . . . . . . . . . 3
	2.2. AFTR Cluster . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. AFTR Cluster . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. IPv4 Address Plus Ports to IPv6 Binding Table		2.3. IPv4 Address Plus Ports to IPv6 Binding Table
	Considerations . . . . . . . . . . . . . . . . . . . . . . 4		Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	2.4. IPv6 and IPv4 Anycast Considerations . . . . . . . . . . . 5		2.4. IPv6 and IPv4 Anycast Considerations . . . . . . . . . . . 5
	2.5. Load Balancing across Multiple Concentrators . . . . . . . 6		2.5. Load Balancing across Multiple Concentrators . . . . . . . 7
	2.6. DHCPv6 Tunnel End-point Option Considerations . . . . . . . 6		2.6. DHCPv6 Tunnel End-point Option Considerations . . . . . . . 7
	2.7. CPE IPv6 Address Management . . . . . . . . . . . . . . . . 6		2.7. CPE IPv6 Address Management . . . . . . . . . . . . . . . . 7
	2.8. Binding Table Synchronization . . . . . . . . . . . . . . . 6		2.8. Binding Table Synchronization . . . . . . . . . . . . . . . 7
	2.9. Subscriber Management and Growth . . . . . . . . . . . . . 7		2.9. Subscriber Management and Growth . . . . . . . . . . . . . 8
	2.10. Privacy Extensions . . . . . . . . . . . . . . . . . . . . 7		2.10. Privacy Extensions . . . . . . . . . . . . . . . . . . . . 8
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 8		6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	DS-Lite [RFC6333] is a solution to deal with the IPv4 exhaustion		DS-Lite [RFC6333] is a solution to deal with the IPv4 exhaustion
	problem once an IPv6 access network is deployed. It enables		problem once an IPv6 access network is deployed. It enables
	unmodified IPv4 applications to access the IPv4 Internet over the		unmodified IPv4 applications to access the IPv4 Internet over the
	IPv6 access network. In the DS-Lite architecture, global IPv4		IPv6 access network. In the DS-Lite architecture, global IPv4
	addresses are shared amongst subscribers as the concentrator (AFTR)		addresses are shared amongst subscribers as the concentrator (AFTR)
	performs a Carrier-Grade NAT (CGN) function.		performs a Carrier-Grade NAT (CGN) function.
	[I-D.cui-softwire-b4-translated-ds-lite] extends the original DS-Lite		[I-D.cui-softwire-b4-translated-ds-lite] describes Lightweight
	model so that NAT is performed by the CPE and IPv4 address sharing is		4over6, which extends the original DS-Lite model so that NAT is
	possible through the use of source port-restrictions.		performed by the CPE and IPv4 address sharing is possible through the
			use of source port-restrictions. AFTRs which only implement the
			functionality required for lw4o6 (i.e. tunnel concentration without a
			CGN function) are referred to as lwAFTRs.
	This memo provides an operational architecture for the deployment of		This memo provides an operational architecture for the deployment of
	Lightweight 4over6 [I-D.cui-softwire-b4-translated-ds-lite] offering		Lightweight 4over6, offering scalability and high-availability whilst
	scalability and high-availability whilst preserving the per-flow		preserving the per-flow stateless nature of the solution.
	stateless nature of the solution.
	The approach presented here is stateless and deterministic. It		The approach presented here is stateless and deterministic. It
	leverages the stateless properties of Lightweight 4over6 to offer a		leverages the stateless properties of Lightweight 4over6 to offer a
	completely deterministic solution. The bindings between IPv4		completely deterministic solution. The bindings between IPv4
	addresses, ports and IPv6 addresses are pre-computed and stored		addresses, ports and IPv6 addresses are pre-computed and stored
	identically in the AFTRs and DHCP servers. This allows for a very		identically in the lwAFTRs and DHCP servers. This allows for a very
	simple fail-over mechanism within a cluster of identically		simple fail-over mechanism within a cluster of identically
	provisioned AFTRs.		provisioned lwAFTRs.
			The deterministic architecture is unsuited to per-flow stateful
			approaches such as DS-Lite, as by their nature, states are
			dynamically created / deleted and would need to be syncronised in
			real time between all of the AFTRs in a single cluster to function
			correctly. This syncronisation greatly increases the complexity of
			the AFTR and is not required by lwAFTRs.
	2. Deterministic Architecture		2. Deterministic Architecture
	2.1. Distribution of the Subscriber Population		2.1. Distribution of the Subscriber Population
	In a large deployment, it makes sense to distribute the subscriber		In a large deployment, it makes sense to distribute the subscriber
	population into subscriber groups, managed by a single AFTR, or by		population into subscriber groups, managed by a single lwAFTR, or by
	many AFTRs grouped in a cluster. Topological considerations and		many lwAFTRs grouped in a cluster. Topological considerations and
	geographical proximity may also be factors in the grouping of		geographical proximity may also be factors in the grouping of
	subscribers. The exact size of those groups depend on the capacity		subscribers. The exact size of those groups depend on the capacity
	characteristics of the AFTRs and is out of scope for this memo.		characteristics of the lwAFTRs and is out of scope for this memo.
	Each subscriber group is assigned an IPv6 anycast address and a pool		Each subscriber group is assigned an IPv6 anycast address and a pool
	of IPv4 addresses which are common to all AFTRs in a cluster. The		of IPv4 addresses which are common to all lwAFTRs in a cluster. The
	IPv4 pool must be sized to handle the subscriber population. No		IPv4 pool must be sized to handle the subscriber population. No
	constraints are placed upon the addresses that are used for this		constraints are placed upon the addresses that are used for this
	pool, in that they can be taken from a single, contiguous block,		pool, in that they can be taken from a single, contiguous block,
	multiple non-contiguous blocks or single IPv4 addresses as required		multiple non-contiguous blocks or single IPv4 addresses as required
	by the operator.		by the operator.
	The exact ratio subscribers to IPv4 addresses, (e.g. the average		The exact ratio subscribers to IPv4 addresses, (e.g. the average
	number of ports assigned per subscriber) is out of scope for this		number of ports assigned per subscriber) is out of scope for this
	memo.		memo.
	2.2. AFTR Cluster		2.2. AFTR Cluster
	All AFTRs within a cluster are configured with identical lW4o6		All lwAFTRs within a cluster are configured with identical lw4o6
	parameters. In particular, they are configured with the same:		parameters. In particular, they are configured with the same:
	o IPv6 AFTR tunnel end-point address		o IPv6 lwAFTR tunnel end-point address
	o IPv4 public pool		o IPv4 public pool
	o IPv6 address to IPv4 address and port binding table		o IPv6 address to IPv4 address and port binding table
	2.3. IPv4 Address Plus Ports to IPv6 Binding Table Considerations		2.3. IPv4 Address Plus Ports to IPv6 Binding Table Considerations
	The DHCPv4 over IPv6 server will provide each IPv6 CPE an IPv4		The DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] server will
	address and port range to use within its local NAT binding table.		provide each IPv6 CPE an IPv4 address and port range to use within
	The DHCPv4 server uses the IPv6 address of the CPE as its identifier.		its local NAT binding table. The DHCPv4 server uses the IPv6 address
	As such, the DHCPv4 server contains a table for assigning a specific		of the CPE as its identifier. As such, the DHCPv4 server contains a
	IPv4 address and ports based on the IPv6 address of the requesting		table for assigning a specific IPv4 address and ports based on the
	CPE. To maintain the stateless nature of the architecture, DHCPv4		IPv6 address of the requesting CPE. To maintain the stateless nature
	reservation based address assignment is recommended. The lease time		of the architecture, DHCPv4 reservation based address assignment is
	for the IPv4 address is unimportant, although a long lease time (or		recommended. The lease time for the IPv4 address is unimportant,
	even infinity) is recommended to reduce the number of DHCPv4		although a long lease time (or even infinity) is recommended to
	requests.		reduce the number of DHCPv4 requests.
	A similar table (containing the same address/port binding		A similar table (containing the same address/port binding
	information) is also present on all AFTRs in the cluster.		information) is also present on all lwAFTRs in the cluster.
	The following table shows sample CPE configuration data for a		The following table shows sample CPE configuration data for a
	subscriber group. In order for the system to function coherently,		subscriber group. In order for the system to function coherently,
	this data needs to be kept synchronised between all of the functional		this data needs to be kept synchronised between all of the functional
	elements (AFTRs and DHCPv4o6 servers) serving the subscriber group.		elements (lwAFTRs and DHCPv4o6 servers) serving the subscriber group.
	+--------------+------------+----------+		+--------------+------------+----------+
	| IPv6 address |IPv4 address|port-range|		| IPv6 address |IPv4 address|port-range|
	+--------------+------------+----------+		+--------------+------------+----------+
	|2001:db8::1 | 1.2.3.4 | 1000-1999|		|2001:db8::1 | 1.2.3.4 | 1000-1999|
	|2001:0:1::2 | 1.2.3.4 | 2000-2999|		|2001:0:1::2 | 1.2.3.4 | 2000-2999|
	|2001:0:5::1 | 2.3.4.5 | 1500-3999|		|2001:0:5::1 | 2.3.4.5 | 1500-3999|
	+--------------+------------+----------+		+--------------+------------+----------+
	Figure 1 DHCP4o6/AFTR Per-subscriber configuration table data example		Figure 1 DHCP4o6/lwAFTR Per-subscriber configuration table data
			example
	This memo proposes a simple architecture to guarantee the		This memo proposes a simple architecture to guarantee the
	synchronization of those mapping tables and rely on anycast IPv4 and		synchronization of those mapping tables and rely on anycast IPv4 and
	IPv6 technologies to provide failover within the AFTRs in the same		IPv6 technologies to provide failover within the lwAFTRs in the same
	cluster.		cluster.
	2.4. IPv6 and IPv4 Anycast Considerations		2.4. IPv6 and IPv4 Anycast Considerations
	The following diagram shows the architecture for the Lightweight		The following diagram shows the architecture for the Lightweight
	4over6 cluster deployment.		4over6 cluster deployment.
	^		^
	| To public Internet		| To public Internet
	Public IPv4 Address | (IPv4)		Public IPv4 Address | (IPv4)
	pool advertised into |		pool advertised into |
	upstream routing |		upstream routing |
	by all AFTRs +-------+-------+		by all lwAFTRs +-------+-------+
	in cluster | |		in cluster | |
	| Upstream |		| Upstream |
	+- - - - - - - - - - >| IPv4 Anycast |		+- - - - - - - - - - >| IPv4 Anycast |
	| +--+----+----+--+		| +--+----+----+--+
	| | |		| | |
	| | | |		| | | |
	+---------------------+ | +---------------------+		+---------------------+ | +---------------------+
	| | | |		| | | |
	+----+--+-------+ +-------+ ------+ +-------+-------+		+----+--+-------+ +-------+ ------+ +-------+-------+
	| | | | | |		| | | | | |
	| LW4o6 | | LW4o6 | | LW4o6 |		| lw4o6 | | lw4o6 | | lw4o6 |
	| AFTR1 | | AFTR2 | . . . . | AFTRn |		| lwAFTR1 | | lwAFTR2 | . . . . | lwAFTRn |
	| | | | | |		| | | | | |
	+----+--+-------+ +-------+-------+ +-------+-------+		+----+--+-------+ +-------+-------+ +-------+-------+
	| | | |		| | | |
	+---------------------+ | +---------------------+		+---------------------+ | +---------------------+
	| | | |		| | | |
	| | |		| | |
	| +--+----+----+--+		| +--+----+----+--+
	+- - - - - - - - - - >| |		+- - - - - - - - - - >| |
	| Downstream |		| Downstream |
	IPv6 tunnel end-point | IPv6 Anycast |		IPv6 tunnel end-point | IPv6 Anycast |
	Anycast Address +-------+-------+		Anycast Address +-------+-------+
	advertized into |		advertized into |
	downstream routing |		downstream routing |
	by all AFTRS | To Initiator		by all lwAFTRS | To Initiator
	in cluster | Access network		in cluster | Access network
	| (IPv6 only)		| (IPv6 only)
	v		v
	Figure 2 Lightweight 4over6 Cluster		Figure 2 Lightweight 4over6 Cluster
	To increase service availability, A simple way to achieve fail-over		To increase service availability, A simple way to achieve fail-over
	is to configure both the IPv6 tunnel end point address and the IPv4		is to configure both the IPv6 tunnel end point address and the IPv4
	address pool as anycast addresses on the AFTRs and announce these		address pool as anycast addresses on the lwAFTRs and announce these
	routes into the IGP run by the ISP, such as OSPF or IS-IS.		routes into the IGP run by the ISP, such as OSPF or IS-IS.
	The number of AFTRs in a cluster provides the degree of redundancy of		The number of lwAFTRs in a cluster provides the degree of redundancy
	the solution. In practice, two AFTRs are expected to be sufficient		of the solution. In practice, two lwAFTRs are expected to be
	in most cases.		sufficient in most cases.
	2.5. Load Balancing across Multiple Concentrators		2.5. Load Balancing across Multiple Concentrators
	AFTR functionality can be scaled by load balancing the encapsulation/		lwAFTR functionality can be scaled by load balancing the
	decapsulation across multiple AFTRs in a cluster. Due to the		encapsulation/decapsulation across multiple lwAFTRs in a cluster.
	commonality of configuration and stateless nature of the solution,		Due to the commonality of configuration and stateless nature of the
	any tunneled packet from any Initiator served by the cluster can		solution, any tunneled packet from any Initiator served by the
	arrive at any cluster member and will be processed in the same way.		cluster can arrive at any cluster member and will be processed in the
	Likewise, for inbound packets originating in the IPv4 realm, a packet		same way. Likewise, for inbound packets originating in the IPv4
	that arrives at any of the cluster member will be encapsulated and		realm, a packet that arrives at any of the cluster member will be
	sent to the correct initiator.		encapsulated and sent to the correct initiator.
	Load balancing could be achieved using specific load balancing		Load balancing could be achieved using specific load balancing
	infrastructure to distribute the tunnels and inbound v4 traffic		infrastructure to distribute the tunnels and inbound v4 traffic
	across the cluster. It is also possible to use the Equal Cost		across the cluster. It is also possible to use the Equal Cost
	Multipath inherent in some routing protocols to achieve this.		Multipath inherent in some routing protocols to achieve this.
	In order to prevent out-of-sequence packets in the tunnelled traffic,		In order to prevent out-of-sequence packets in the tunnelled traffic,
	a mechanism for forwarding all packets belonging to a single tunnel		a mechanism for forwarding all packets belonging to a single tunnel
	through the same cluster member should be used. An example of this		through the same cluster member should be used. An example of this
	would be a source/destination hashing algorithm such as [RFC2992]		would be a source/destination hashing algorithm such as [RFC2992]
	describes.		describes.
	2.6. DHCPv6 Tunnel End-point Option Considerations		2.6. DHCPv6 Tunnel End-point Option Considerations
	All CPEs belonging to the same group of subscribers need to receive		All CPEs belonging to the same group of subscribers need to receive
	the same tunnel end-point option (via DHCPv6). This will be set to		the same tunnel end-point option (via DHCPv6). This will be set to
	the IPv6 anycast address of the AFTR cluster.		the IPv6 anycast address of the lwAFTR cluster.
	2.7. CPE IPv6 Address Management		2.7. CPE IPv6 Address Management
	The DHCPv4 server uses the IPv6 address of the CPE as its index. In		The DHCPv4 server uses the IPv6 address of the CPE as its index. In
	order to keep the overall service architecture flexible and		order to keep the overall service architecture flexible and
	adaptable, it is preferable that the CPE is configured using DHCPv6		adaptable, it is preferable that the CPE is configured using DHCPv6
	out of a specific pool reserved by the ISP.		out of a specific pool reserved by the ISP.
	2.8. Binding Table Synchronization		2.8. Binding Table Synchronization
	It is proposed that binding tables be pre-computed and stored		It is proposed that binding tables be pre-computed and stored
	statically on the AFTRs and the DHCPv4 servers. The method of		statically on the lwAFTRs and the DHCPv4 servers. The method of
	creating the binding tables is out of the scope of this memo.		creating the binding tables is out of the scope of this memo.
	These tables are not expected to change regularly. Typical reasons		These tables are not expected to change regularly. Typical reasons
	for an update include adding or removing an IPv4 address block, or		for an update include adding or removing an IPv4 address block, or
	changing the size of IPv4 ports ranges available to each CPE.		changing the size of IPv4 ports ranges available to each CPE.
	To ensure continuous operation, binding tables have to be updated		To ensure continuous operation, binding tables have to be updated
	simultaneously across all AFTRs in a cluster by a mechanism such as		simultaneously across all lwAFTRs in a cluster by a mechanism such as
	netconf. It may also be necessary to reconfigure CPEs during this		netconf. It may also be necessary to reconfigure CPEs during this
	process (e.g. via a DHCPv6 reconifgure message). The details are out		process (e.g. via a DHCPv6 reconifgure message). The details are out
	of scope for this memo.		of scope for this memo.
	2.9. Subscriber Management and Growth		2.9. Subscriber Management and Growth
	It is recommended that the ISP predefines all IPv6 addresses and		It is recommended that the ISP predefines all IPv6 addresses and
	corresponding IPv4 addresses and port ranges for any given subscriber		corresponding IPv4 addresses and port ranges for any given subscriber
	group.		group.
	skipping to change at page 7, line 39 ¶		skipping to change at page 8, line 31 ¶
	users privacy.		users privacy.
	This can be achieve by rolling over the IPv6 addresses in the DHCPv6		This can be achieve by rolling over the IPv6 addresses in the DHCPv6
	server allocating IPv6 addresses to the CPE. If all subscribers		server allocating IPv6 addresses to the CPE. If all subscribers
	within the subscriber group are allocated the same number of ports in		within the subscriber group are allocated the same number of ports in
	IPv4, then the IPv6 to IPv4 address and port binding may remain the		IPv4, then the IPv6 to IPv4 address and port binding may remain the
	same, the IPv4 address and ports will then roll over automatically at		same, the IPv4 address and ports will then roll over automatically at
	the same time as the IPv6 addresses do.		the same time as the IPv6 addresses do.
	[I-D.cui-softwire-b4-translated-ds-lite] states that when the IPv6		[I-D.cui-softwire-b4-translated-ds-lite] states that when the IPv6
	address of the B4 is changed, then DHCPv4over6 configuration process		address of the lwB4 is changed, then DHCPv4over6 configuration
	must be re-initiated.		process must be re-initiated.
	3. IANA Considerations		3. IANA Considerations
	None.		None.
	4. Security Considerations		4. Security Considerations
	None.		None.
	5. Acknowledgements		5. Acknowledgements
	skipping to change at page 8, line 8 ¶		skipping to change at page 9, line 4 ¶
	None.		None.
	4. Security Considerations		4. Security Considerations
	None.		None.
	5. Acknowledgements		5. Acknowledgements
	6. References		6. References
	6.1. Normative References		6.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.
	[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path		[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
	Algorithm", RFC 2992, November 2000.		Algorithm", RFC 2992, November 2000.
	[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-		[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4		Stack Lite Broadband Deployments Following IPv4
	Exhaustion", RFC 6333, August 2011.		Exhaustion", RFC 6333, August 2011.
	6.2. Informative References		6.2. Informative References
	[I-D.cui-softwire-b4-translated-ds-lite]		[I-D.cui-softwire-b4-translated-ds-lite]
	Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.		Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
	Farrer, "Lightweight 4over6: An Extension to the DS-Lite		Farrer, "Lightweight 4over6: An Extension to the DS-Lite
	Architecture", draft-cui-softwire-b4-translated-ds-lite-07		Architecture", draft-cui-softwire-b4-translated-ds-lite-08
	(work in progress), July 2012.		(work in progress), September 2012.
			[I-D.ietf-dhc-dhcpv4-over-ipv6]
			Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
			Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in
			progress), September 2012.
	Authors' Addresses		Authors' Addresses
	Ian Farrer		Ian Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	GTN-FM4		GTN-FM4
	Landgrabenweg 151		Landgrabenweg 151
	Bonn 53227		Bonn 53227
	Germany		Germany
End of changes. 30 change blocks.
	104 lines changed or deleted		117 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/