< draft-ietf-softwire-lightweight-4over6-deployment-00.txt		draft-ietf-softwire-lightweight-4over6-deployment-01.txt >
	Network Working Group Q. Sun		Network Working Group Q. Sun
	Internet-Draft C. Xie		Internet-Draft C. Xie
	Intended status: Informational China Telecom		Intended status: Informational China Telecom
	Expires: July 29, 2017 Y. Lee		Expires: January 4, 2018 Y. Lee
	Comcast		Comcast
	M. Chen		M. Chen
	FreeBit		FreeBit
	T. Li		T. Li
	Tsinghua University		Tsinghua University
	January 25, 2017		I. Farrer
			Deutsche Telekom AG
			July 3, 2017
	Deployment Considerations for Lightweight 4over6		Deployment Considerations for Lightweight 4over6
	draft-ietf-softwire-lightweight-4over6-deployment-00		draft-ietf-softwire-lightweight-4over6-deployment-01
	Abstract		Abstract
	Lightweight 4over6 is a mechanism which moves the translation		Lightweight 4over6 is a mechanism for providing IPv4 services to
	function from tunnel lwAFTR (AFTR) to lwB4s (B4s), and hence reduces		clients connected to a single-stack IPv6 network. The architecture
	the mapping scale on the lwAFTR to per-customer level. This document		is similar to DS-Lite, but the network address translation function
	discusses various deployment models of Lightweight 4over6. It also		is relocated from the tunnel concentrator to the tunnel client, hence
	describes the deployment considerations and applicability of the		reducing the amount of state which must be maintained in the
	Lightweight 4over6 architecture.		concentrator to a per-customer level. This document discusses the
			applicability, describes various deployment models and provides
			deployment considerations for Lightweight 4over6.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 29, 2017.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 4		2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overall Deployment Considerations . . . . . . . . . . . . . . 6		2.1. Top-Down Deployment Model . . . . . . . . . . . . . . . . 4
	3.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 6		2.2. Bottom-Up Deployment Model . . . . . . . . . . . . . . . 5
	3.2. Port-set Management . . . . . . . . . . . . . . . . . . . 6		2.3. Campus Deployment . . . . . . . . . . . . . . . . . . . . 5
	3.3. lwAFTR Discovery . . . . . . . . . . . . . . . . . . . . . 7		3. Overall Deployment Considerations . . . . . . . . . . . . . . 5
	3.4. Impacts on Accouting . . . . . . . . . . . . . . . . . . . 7		3.1. IP Addressing and Routing . . . . . . . . . . . . . . . . 5
	4. lwAFTR Deployment Consideration . . . . . . . . . . . . . . . 8		3.1.1. IPv4 Routing . . . . . . . . . . . . . . . . . . . . 5
	4.1. Logging at the lwAFTR . . . . . . . . . . . . . . . . . . 8		3.1.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . . 6
	4.2. MTU and Fragmentation Considerations . . . . . . . . . . . 8		3.2. lwB4 Configuration . . . . . . . . . . . . . . . . . . . 6
	4.3. Reliability Considerations of lwAFTR . . . . . . . . . . . 8		3.2.1. DHCPv6 Based Provisioning . . . . . . . . . . . . . . 6
	4.4. Placement of AFTR . . . . . . . . . . . . . . . . . . . . 9		3.2.2. DHCPv4 over DHCPv6 Based Provisioning . . . . . . . . 7
	4.5. Port set algorithm consideration . . . . . . . . . . . . . 9		3.2.3. PCP Based Provisioning . . . . . . . . . . . . . . . 7
	4.6. Path Consistency Consideration . . . . . . . . . . . . . . 9		3.2.4. NETCONF/YANG Based Provisioning . . . . . . . . . . . 7
	5. lwB4 Deployment Consideration . . . . . . . . . . . . . . . . 11		3.2.5. Other lwB4 Configuation Considerations . . . . . . . 7
	5.1. NAT traversal issue . . . . . . . . . . . . . . . . . . . 11		3.3. lwAFTR Discovery . . . . . . . . . . . . . . . . . . . . 8
	5.2. Static Port Forwarding Configuration . . . . . . . . . . . 11		3.4. Impacts on Accouting . . . . . . . . . . . . . . . . . . 8
	6. DS-Lite Compatibility Consideration . . . . . . . . . . . . . 12		4. lwAFTR Deployment Considerations . . . . . . . . . . . . . . 8
			4.1. Logging at the lwAFTR . . . . . . . . . . . . . . . . . . 9
			4.2. MTU and Fragmentation Considerations . . . . . . . . . . 9
			4.3. Reliability Considerations of lwAFTR . . . . . . . . . . 9
			4.4. Location of lwAFTRs in the Network . . . . . . . . . . . 10
			4.5. Path Consistency Consideration . . . . . . . . . . . . . 10
			5. lwB4 Deployment Considerations . . . . . . . . . . . . . . . 11
			5.1. NAT Traversal Issues . . . . . . . . . . . . . . . . . . 11
			5.2. Static Port Forwarding Configuration . . . . . . . . . . 11
			6. DS-Lite Compatibility Consideration . . . . . . . . . . . . . 12
	6.1. Case 1: Integrated Network Element with Lightweight		6.1. Case 1: Integrated Network Element with Lightweight
	4over6 and DS-Lite AFTR Scenario . . . . . . . . . . . . . 12		4over6 and DS-Lite AFTR Scenario . . . . . . . . . . 12
	6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR . 13		6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR . 13
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix 1. China Telecom Experimental Result . . . . . . . . . . 18		Appendix A. China Telecom Experimental Results . . . . . . . . . 17
	1.1. Experimental Environment . . . . . . . . . . . . . . . . . 18		A.1. Experimental Environment . . . . . . . . . . . . . . . . 18
	1.2. Experimental Results . . . . . . . . . . . . . . . . . . . 19		A.2. Experimental Results . . . . . . . . . . . . . . . . . . 19
	1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 20		A.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix 2. Tsinghua University Experimental Result . . . . . . . 21		Appendix B. Tsinghua University Experimental Result . . . . . . 20
	2.1. Experimental Environment . . . . . . . . . . . . . . . . . 21		B.1. Experimental Environment . . . . . . . . . . . . . . . . 20
	2.2. Experimental Results . . . . . . . . . . . . . . . . . . . 22		B.2. Experimental Results . . . . . . . . . . . . . . . . . . 21
	2.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22		B.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to		Lightweight 4over6 [RFC7596] (lw4o6) is an extension to DS-Lite
	DS-Lite which simplifies the AFTR module [RFC6333] with distributed		[RFC6333] which simplifies the AFTR module by relocating the NAPT
	NAT function among B4 elements. The lwB4 in Lightweight 4over6 is		function among B4 elements located at the subscriber's premises. In
	provisioned with an IPv6 address, an IPv4 address and a port-set. It		the lw4o6 architecture, the functional elements are referred to as
	performs NAPT on end user's packets with the provisioned IPv4 address		the lwB4 and lwAFTR.
	and port-set. IPv4 packets are forwarded between the lwB4 and the
	lwAFTR over a Softwire using IPv4-in-IPv6 encapsulation. The lwAFTR
	maintains one mapping entry per subscriber with the IPv6 address,
	IPv4 address and port-set. Therefore, this extension removes the
	NAT44 module from the AFTR and replaces the session-based NAT table
	to a per-subscriber based mapping table. This should relax the
	requirement to create dynamic session-based log entries. This
	mechanism preserves the dynamic feature of IPv4/IPv6 address binding
	as in DS-Lite, so it has no coupling between IPv6 address and IPv4
	address/port-set as any full stateless solution ([RFC6052] or
	[I-D.ietf-softwire-map]) requires. This document discusses
	deployment models of Lightweight 4over6. It also describes the
	deployment considerations and applicability of the Lightweight 4over6
	architecture.
	Terminology of this document follows the definitions and		The lwB4 is provisioned with an IPv6 address, a public IPv4 address
	abbreviations of [I-D.ietf-softwire-lw4over6].		and a port-set. It performs port-restricted NAPT on subscriber's
			packets using the provisioned public IPv4 address and port-set. IPv4
			packets are routed between the lwB4 and the lwAFTR encapsulated in an
			IPv4 in IPv6 Softwire. The lwAFTR maintains one binding entry per-
			subscriber, consisting of the lwB4's IPv6 tunnel endpoint, IPv4
			address and port-set. Section 4.4 of [RFC6346] provides more detail
			of this mechanism.
	2. Deployment Model		This can bring a number of advantages when compared to DS-Lite:
			o Per-subscriber configuration allows for the operator to provision
			each subscriber according to their specific service requirements.
			o The logging requirements to meet regulatory requirements may be
			reduced as it is only necessary to log when a subscriber is
			provisioned or de-provisioned in the lwAFTR. This relaxes the
			need for logging on a per-session, or per port block allocation.
			o In some lw4o6 deployment topologies, the removal of per-session
			state means that it is possible to have very large parallelisation
			of lwAFTR elements. This offers excellent scaling and resilience.
			o This mechanism preserves the dynamic feature of IPv4/IPv6 address
			binding as in DS-Lite, so it has no coupling between IPv6 address
			and IPv4 address/port-set as any full stateless solution
			([RFC6052] or [RFC7597]) requires.
			The terminology used in this document follows the definitions and
			abbreviations from [RFC6333] and [RFC7596].
			2. Deployment Models
	Lightweight 4over6 is suitable for operators who would like to free		Lightweight 4over6 is suitable for operators who would like to free
	any correlation of the IPv6 address with IPv4 address and port-set		any correlation of the IPv6 address with IPv4 address and port-set,
	(or port-range). In comparison to full stateless solutions like MAP		as the IPv4 addressing is an overlay to the IPv6 addressing
	[I-D.ietf-softwire-map] and 4rd [I-D.ietf-softwire-4rd], Lightweight		architecture. Thus, IPv6 addressing is completely flexible to fit
	4over6 frees address planning of IPv6 delegation for CPE from mapping		other deployment requirements, e.g., auto-configuration, service
	rule administration and management in the network. Thus, IPv6		classification, user management, QoS support, etc.
	addressing is completely flexible to fit other deployment
	requirements, e.g., auto-configuration, service classification, user
	management, QoS support, etc. The philosophy here is that bits of
	IPv6 address should be left for IPv6 usage first.
	Lightweight 4over6 can be deployed in a residential network (depicted		Lightweight 4over6 can be deployed in a residential ISP network
	in Figure1). In this scenario, a lwB4 would acquire an IPv4 address		(depicted in Figure 1). In this scenario, a lwB4 acquires an IPv4
	and a port-set after a successful user authentication process and		address and a port-set alongside IPv6 provisioning, including an
	IPv6 provisioning process. Then, it establishes an IPv4-in-IPv6		address for the lwAFTR. It then establishes an IPv4-in-IPv6 softwire
	softwire using the IPv6 address to deliver IPv4 services to its		to the lwAFTR. The lwB4 function may be implemented in a CPE
	connected host via the lwAFTR in the network. The lwB4 can act as a		providing IPv4 services for a home network, or directly in a host.
	CPE, or software located in the host. The lwAFTR supports
	Lightweight 4over6 which keeps the mapping between lwB4's IPv6		The lwAFTR holds a table with the bindings between the lwB4's IPv6
	address and its allocated IPv4 address + port set. The supporting		addresses and their allocated IPv4 addresses + port sets. The
	system may keep the binding information as well for logging and user		supporting system is used to syncronise the lwB4 and lwAFTR binding
	management.		information. It may also be used for logging and user management.
	+---------------+		+---------------+
	| Supporting |		| Supporting |
	| System |		| System |
	+-------+-------+		+-------+-------+
	|		|
	+---------------+--------------|		+---------------+-------------+
	| | |		| |
	+---------+ +------+---+ +--+--+ |		+---------+ +------+---+ |
	| Host | | lwB4 | | | |		| Host | | lwB4 | _ _ |
	| |--| | ======-| BNG | === +---------+ +-----------+		| |--| |=======( ` )=======+----+----+ +-----------+
	+---------+ +----------+ +--|--+ | | | IPv4 |		+---------+ +----------+ ( ) _ | | | IPv4 |
	| lwAFTR |---| Internet |		( IPv6 ) ) | lwAFTR |---| Internet |
	+---------+ +------+---+ +--+--+ | | | |		+---------+ +------+---+ ( Network ) | | | |
	| Host |--| lwB4 | =======| | ====+---------+ +-----------+		| Host |--| lwB4 |====( ( ) ====+---------+ +-----------+
	| | | | | BNG | |		| | | | `(_, __)
	+---------+ +----------+ +--|--+ |		+---------+ +----------+
	+ | |
	+---------------+--------------+
	Figure 1 Deployment Model		---------+ +----------+
			Figure 1 Architectural Overview
	There are two deployment models in practice: one is called bottom-up		2.1. Top-Down Deployment Model
	and the other is top-down. In bottom-up model, after port-restricted
	IPv4 address is allocated to a given subscriber, the lwAFTR will		In the top-down deployment model, the supporting system holds the
	report mapping records to the supporting system on creating a binding		overall binding table for the network. It uses this to pre-provision
	for traffic logging if necessary. Operators may use		the local binding table entries for the lwAFTR and also provision
			lwB4s with the correct configuration (e.g. using DHCPv6 or PCP).
			With this method, one binding table entry can be present on lwAFTRs
			and stateless failover can be achieved.
			2.2. Bottom-Up Deployment Model
			In the bottom-up model, the client is first provisioned with the
			relevant paramters necessary for building the softwire. It then
			attempts to send traffic to the lwAFTR.
			On receipt of lwB4 traffic which does not have an existing binding-
			table entry, one is dynamically created. The lwAFTR reports the new
			binding entry to the supporting system.
	[I-D.ietf-behave-syslog-nat-logging] or		[I-D.ietf-behave-syslog-nat-logging] or
	[I-D.ietf-behave-ipfix-nat-logging] to report the port set allocated		[I-D.ietf-behave-ipfix-nat-logging] may be used for this purpose. In
	by lwAFTR. In this way, the lwAFTR can determine the binding by its		this way, the lwAFTR can determine the binding by its own and there
	own and there is little impact on existing network architecture. In		is little impact on existing network architecture.
	top-down model, the Supporting system should firstly determine the
	binding information for each subscriber and then synchronize it with		2.3. Campus Deployment
	the lwAFTR. With this method, one binding record can be easily
	synchronized with multiple lwAFTRs and stateless failover can be
	achieved. However, new mechanism (e.g.
	[I-D.zhou-dime-4over6-provisioning]) needs to be introduced to notify
	each individual binding record between the Supporting system and the
	lwAFTR.
	Lightweight 4over6 can also be deployed in a campus or enterprise		Lightweight 4over6 can also be deployed in a campus or enterprise
	network, (depicted in Figure2). In this scenario, a lwB4 acts as a		network, (depicted in Figure 2). In this scenario, a lwB4 acts as a
	wireless AP and is connected to a number of hosts. The lwB4 first		gateway router for a number of hosts. The lwB4 is first provisioned
	acquire the IPv4 address and port-set information, then it		with an IPv4 address and port-set. It then establishes an IPv4-in-
	establishes an IPv4-in-IPv6 softwire using the IPv6 address to		IPv6 softwire using the IPv6 address to deliver IPv4 services to its
	deliver IPv4 services to its connected host via the lwAFTR in the		connected host via the lwAFTR in the network. A network management
	network. A network management system could be used to receive		system could be used to receive statistic information of the network
	statistic information of the network equipments, such as the binding		equipments, such as the binding table, network load, and connected
	table, network load, and connected device. NETCONF[RFC6241] could be		device. NETCONF [RFC6241] could be used for syncronising lwB4's IPv6
	used for syncronising lwB4's IPv6 address and its allocated IPv4		address and its allocated IPv4 address + port set with the lwAFTR.
	address + port set with the lwAFTR. The network management system		The network management system may keep the binding information as
	may keep the binding information as well for logging and user		well for logging and user management.
	management.
	+-------------------+		3. Overall Deployment Considerations
	| Network Management|
	| System |
	+---------+---------+
	|
	+---------------+--------------|
	| |
	+---------+ | |
	| Host | | |
	| |--+ +----------+ +---------+ +-----------+
	+---------+ | | | | | | IPv4 |
	+ - + lwB4 | ============== | lwAFTR |---| Internet |
	+---------+ | | | | | | |
	| Host |--+ +----------+ +---------+ +-----------+
	| |
	+---------+
	Figure 2 Deployment Model		3.1. IP Addressing and Routing
	3. Overall Deployment Considerations		In Lightweight 4over6, there is no inter-dependency between the IPv4
			and IPv6 addressing schemes. This allows for complete flexibilty in
			addressing architecture.
	3.1. Addressing and Routing		3.1.1. IPv4 Routing
	In Lightweight 4over6, there is no inter-dependency between IPv4 and		The IPv4 addresses/prefixes that are allocated to customer's lwB4s
	IPv6 addressing schemes. IPv4 address pools are configured		are advertised to the IPv4 Internet as being reachable via the
	centralized in lwAFTR for IPv6 subscribers. These IPv4 prefix must		lwAFTR(s). If multiple lwAFTRs are all serving the same set of
	advertise to IPv4 Internet accordingly.		lwB4s, all will advertise the same IPv4 reachable routes.
	For IPv6 addressing and routing, there are no additional addressing		3.1.2. IPv6 Routing
	and routing requirements. The existing IPv6 address assignment and
	routing announcement should not be affected. For example, in PPPoE
	scenario, a CPE could obtain a prefix via prefix delegation
	procedure, and the hosts behind CPE would get its own IPv6 addresses
	within the prefix through SLAAC or DHCPv6 statefully. This IPv6
	address assignment procedure has nothing to do with restricted IPv4
	address allocation.
	3.2. Port-set Management		The lwAFTR provides a /128 IPv6 tunnel endpoint address which is
			advertsed to the lwB4s. If multiple lwAFTRs are all serving the same
			set of lwB4s, all will advertise the same IPv6 tunnel endpoing
			address.
	In Lightweight 4over6, each lwB4 will get its restricted IPv4 address		The lwB4's IPv6 addressing and routing, there are no specific
	and a port-set after successful user authentication process and IPv6		topological limitations. An existing IPv6 address and routing
	provisioning process. This port-set assignment can been achieved by		architecture should not be affected. For example, in PPPoE scenario,
	DHCPv4-over-DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and PCP		a CPE could obtain a prefix via DHCPv6 prefix delegation, and the
	[I-D.ietf-pcp-port-set].		hosts behind CPE would get its own IPv6 addresses within the prefix
			through SLAAC or DHCPv6 statefully. This IPv6 address assignment
			procedure has nothing to do with restricted IPv4 address allocation.
	Operator may use DHCPv4 to provision IPv4 address to the lwB4. In a		It is worth noting that if the Top-Down provisioning model is chosen,
	typical deployment, the DHCP server is a centralized DHCP server and		then there must be determinism in the local address that the lwB4
	lwAFTR is the DHCP relay agent to relay the dhcp messages to the		uses for building its tunnel. This is so that the binding entry for
			the lwB4 can be pre-provisioned in the lwAFTR. [RFC7598] offers a
			solution for this using the 'bind-ipv6-prefix' field is used to
			inform the lwB4 which configured prefix to use. The suffix is then
			created according to Section 6 of [RFC7597].
			3.2. lwB4 Configuration
			In lw4o6, each lwB4 will get its restricted IPv4 address and a port-
			set after successful user authentication process and IPv6
			provisioning process. This assignment can been achieved using a
			number of methods:
			o DHCPv6 Softwire S46 Option [RFC7598]
			o DHCPv4 over DHCPv6 [RFC7341], [RFC7618] and
			[I-D.ietf-dhc-dhcp4o6-saddr-opt]
			o PCP [RFC7753]
			o NETCONF/YANG [I-D.ietf-softwire-yang]
			3.2.1. DHCPv6 Based Provisioning
			[RFC7598] describes a set of DHCPv6 options used for provisioning
			lw4o6 clients. OPTION_S46_CONT_LW (96) is a DHCPv6 contatiner
			option, which can hold the IPv6 of the lwAFTR (OPTION_S46_BR (90)),
			the lwB4's IPv4 address and IPv6 prefix hint (OPTION_S46_V4V6BIND
			(92)), and port set information (OPTION_S46_PORTPARAMS (93)).
			In this model, the DHCPv6 server needs to be pre-provisioned with the
			client configuration. Therefore, this approach is better suited to
			client configurations that will be long-lived.
			DHCPv6 based provisioning can also be used in conjunction with a AAA
			server. [I-D.ietf-softwire-map-radius] decribes this function.
			3.2.2. DHCPv4 over DHCPv6 Based Provisioning
			An operator may use DHCPv4 to provision IPv4 address to the lwB4. In
			a typical deployment, the DHCP server is a centralized DHCP server
			and lwAFTR is the DHCP relay agent to relay the dhcp messages to the
	server over unicast. Rarely DHCP server will collocate with the		server over unicast. Rarely DHCP server will collocate with the
	lwAFTR to provision IPv4 resources to the lwB4.		lwAFTR to provision IPv4 resources to the lwB4.
			3.2.3. PCP Based Provisioning
	Operator may also use PCP Port-set Option to provision IPv4 address		Operator may also use PCP Port-set Option to provision IPv4 address
	and port-set to the lwB4. In a typical deployment, PCP server will		and port-set to the lwB4. In a typical deployment, PCP server will
	collocate with lwAFTR, and the subscriber's binding can be determined		collocate with lwAFTR, and the subscriber's binding can be determined
	by lwAFTR. The PCP request should be sent to the lwAFTR's tunnel		by lwAFTR. The PCP request should be sent to the lwAFTR's tunnel
	end-point address. It is not common that PCP server will be		end-point address. It is not common that PCP server will be
	centralized deployed in which the lwAFTR is the PCP proxy to relay		centralized deployed in which the lwAFTR is the PCP proxy to relay
	PCP requests.		PCP requests.
	It is also possible that subscriber's binding is determined in AAA		3.2.4. NETCONF/YANG Based Provisioning
	server. In this case, the BNGs will embed with a DHCPv4-over-DHCPv6
	server function which allows them to locally handle any DHCPv4-over-		Operators using NETCONF to manage customer devices can provision
	DHCPv6 requests initiated by hosts. The AAA server will pass the		lw4o6 using [I-D.ietf-softwire-yang].
	subscriber's binding to a BNG using the AAA attribute in [I-D.sun-
	softwire-lw4over6-radext] and in turn populates the mapping of the		3.2.5. Other lwB4 Configuation Considerations
	lwB4.
	Some operators may offer different service level agreements (SLA) to		Some operators may offer different service level agreements (SLA) to
	users that some users may require more ports then others. In this		users that some users may require more ports then others. In this
	deployment scenario, the operator can implement differentiated		deployment scenario, the operator can implement differentiated
	policies in provisioning system specified to a user's lwB4 or a group		policies in provisioning system specified to a user's lwB4 or a group
	of lwB4s to allocate a certain range of port-set. The lwAFTR may		of lwB4s to allocate a certain range of port-set. The lwAFTR may
	also run multiple instances with different port-set sizes to build		also run multiple instances with different port-set sizes to build
	the mapping table.		the mapping table.
			It is also worth noting the compatibility between lw4o6 and Public
			IPv4 over IPv6 [RFC7040]. When a lw4o6 client is provisioned with a
			'full' IPv4 address (i.e. with no port-set or a port-set that allows
			the use of all of the L4 ports), then the A+P routing model is no
			longer used by the lwAFTR as traffic is routed on the IPv4 address
			only. This function can be useful when a subscriber usses protocols
			which do not have L4 ports.
	3.3. lwAFTR Discovery		3.3. lwAFTR Discovery
	A Lightweight 4over6 lwB4 must discover the lwAFTR's IPv6 address		The lwB4 needs to discover the lwAFTR's IPv6 address before it is
	before offering any IPv4 services. This IPv6 address can be learned		able to set up the softwire tunnel and provide any IPv4 services.
	through an out-of-band channel, static configuration, or dynamic		This address can be learned through an out-of-band channel, static
	configuration. In practice, Lightweight 4over6 lwB4 can use the same		configuration, or dynamic configuration. In practice, Lightweight
	DHCPv6 option [RFC6334]to discover the FQDN of the lwAFTR.		4over6 lwB4 can use the same DHCPv6 option [RFC6334] to discover the
			FQDN of the lwAFTR.
	When Lightweight 4over6 is deployed in the same place with DS-Lite,		When Lightweight 4over6 is deployed in the same place with DS-Lite,
	either different FQDNs can be configured for Lightweight 4over6 and		either different FQDNs can be configured for Lightweight 4over6 and
	DS-Lite separately or different DHCPv6 options can be used for		DS-Lite separately or different DHCPv6 options can be used for
	Lightweight 4over6 [I-D.sun-softwire-lw4over6-dhcpv6] and DS-Lite.		Lightweight 4over6 [RFC7598] and DS-Lite. More detailed
	More detailed considerations on DS-Lite compatibility will be		considerations on DS-Lite compatibility will be discussed in
	discussed in Section6.		Section 6.
			The lw4o6 DHCPv6 option (OPTION_S46_LW_CONT (96)) can contain
			OPTION_S46_BR (90) which holds the v6 address of the lwAFTR.
	3.4. Impacts on Accouting		3.4. Impacts on Accouting
	In Lightweight 4over6, the accounting impact due to the tunneling		In lw4o6, the accounting impact due to the tunneling protocol is the
	protocol is the same with DS-Lite (see section 6.2 of [RFC6908]).		same with DS-Lite (see section 6.2 of [RFC6908]). However, since in
	However, since in Lightweight 4over6, the IPv4 service is only		lw4o6, the IPv4 service is only available after port-set allocation,
	available after port-set allocation, if operators will regard IPv4		if operators regard IPv4 service as a on-demand value-added service,
	service as a on-demand value-added service, e.g. IPv6 connectivity		e.g. IPv6 connectivity is offered by default, while IPv4
	is offered by default, while IPv4 connectivity will be offered untill		connectivity will be offered untill a subscriber requires, etc., IPv4
	a subscriber requires, etc., IPv4 service accounting should start		service accounting should start after port-set allocation has
	after port-set allocation has completely.		completed.
	4. lwAFTR Deployment Consideration		It should be noted that in common with all A+P mechanisms, lw4o6 can
			not performing per-session logging in the way that CGN based
			solutions do.
			4. lwAFTR Deployment Considerations
	As Lightweight 4over6 is an extension to DS-Lite, both technologies		As Lightweight 4over6 is an extension to DS-Lite, both technologies
	share similar deployment considerations. For example: Interface		share similar deployment considerations. For example: the interface
	consideration, Lawful Intercept Considerations, Blacklisting a shared		considerations, lawful intercept considerations, blacklisting a
	IPv4 Address, AFTR's Policies, AFTR Impacts on Accounting Process,		shared IPv4 Address, AFTR policies, and impacts on accounting
	etc., in [RFC6908] can also be applied here. This document only		processes described in [RFC6908] are also applicable here. This
	discusses new considerations specific to Lightweight 4over6.		document only discusses addtional considerations specific to
			Lightweight 4over6.
	4.1. Logging at the lwAFTR		4.1. Logging at the lwAFTR
	In Lightweight 4over6, operators only log one entry per subscriber.		In lw4o6, operators only log one entry per subscriber. Each log
	The log should include subscriber's IPv6 address used for the		needs to include subscriber's IPv6 address used for the softwire, the
	softwire, the public IPv4 address and the port-set. The port set		public IPv4 address and the allocated port-set, and the start and end
	algorithm implemented in Lightweight 4over6 lwAFTR should be		times that the binding entry was valid for.
	synchronized with the one implemented in logging system. For
	example, if contiguous port set algorithm is adopted in the lwAFTR,
	the same algorithm should also been applied to the logging system.
	Since the mapping in lwAFTR does not contain destination-specific		To ensure consistency of the logged information, the port set
	information, operator should be aware that they will not be able to		algorithm implemented in lw4o6 lwAFTR needs to be synchronized with
	have destination-specific log.		the one implemented in the logging system. For example, if
			contiguous port-set algorithm is adopted in the lwAFTR, the same
			algorithm needs to be applied for the logging system.
			Since the binding in lwAFTR does not log sessions as they are set up,
			operators should be aware that lw4o6 does not provided a mechanism
			for destination-specific logging.
	4.2. MTU and Fragmentation Considerations		4.2. MTU and Fragmentation Considerations
	As Lightweight 4over6 is also a tunneling protocol, the same		As Lightweight 4over6 uses a tunneling protocol, the same
	consideration regarding to the fragmentation and reassembly in DS-		considerations regarding fragmentation and reassembly as for DS-Lite
	Lite [RFC6908] can also be applied. The only difference is that NAT		[RFC6908] are applicable. In order to avoid the problems that are
	functionality has been removed to lwB4 from lwAFTR in Lightweight		associated with fragmentation, it is advisable to ensure that the MTU
	4over6. Therefore, on receiving an IPv4 fragmented packet after		across the IPv6 domain between the lwB4 and lwAFTR is large enough to
	decapsulation in the lwB4, the lwB4 should further re-assemble the		allow for the transportation of IPv4 packets plus the 40-byte
	packets before doing NAT since the transport protocol information is		overhead for IPv6 encapsulation.
	only available in the first fragment.
	4.3. Reliability Considerations of lwAFTR		4.3. Reliability Considerations of lwAFTR
	Operators may deploy multiple lwAFTRs for robustness, reliability,		Operators may deploy multiple lwAFTRs for robustness, reliability,
	and load balancing. In Lightweight 4over6, subscriber to IPv4 and		and load balancing. In lw4o6, subscriber to IPv4 and port-set
	port-set mapping must be pre-provisioned in the lwAFTR before		mapping needs to be pre-provisioned in the lwAFTR before an IPv4
	providing IPv4 serives. For redundancy, the backup lwAFTR must		service can be provided.
	either have the subscriber mapping already provisioned or notify the
	lwB4 to create a new mapping in the backup lwAFTR. The first option
	can be considered as Hot Standby mode, which requires state
	syncronization between multiple lwAFTRs. In Hot Standby mode, the
	bindings are replicated on-the-fly from the Primary lwAFTR to the
	Backup lwAFTR. When the Primary lwAFTR fails, the Backup lwAFTR will
	take over all the existing established sessions. In this mode, the
	internal hosts are not required to re-initiate the bindings with the
	external hosts. In Lightweight 4over6, since the number of mapping
	states has been greatly reduced compared to DS-Lite, it is reasonable
	to adopt Hot Standby mode when there are only two lwAFTRs (one for
	Primary lwAFTR and one for Backup lwAFTR). However, if the number of
	lwAFTRs is larger than two, it is not scalable to deploy Hot Standby
	mode since each two of the lwAFTRs should to syncronize the binding
	states.
	The second option is to use Cold Standby mode which does not require		For redundancy, one or more backup lwAFTR can have the subscriber
	a Backup Standby lwAFTR to synchronize binding states. In failover,		bindings already provisioned, e.g. as part of the top-down
	the lwAFTR has to notify the lwB4 to create a new binding, or fetch		provisioning process described above. In this case, the provisioning
	the binding by itself. [I-D.lee-softwire-lw4over6-failover]		system is responsible for ensuring that the binding tables of the
	describes these two approaches for simple Cold Standby mode. For		lwAFTRS are consistent. In this case, as customer traffic arriving
	most deployment scenarios, we believe that Cold Standby mode should		or returning through either of the lwAFTRs will be processed in the
	be sufficient enough and is thus recommended.		same way, an active/active redundancy model is possbile.
	4.4. Placement of AFTR		A second option, which could be more suitable for bottom-up
			provisioning, is for the bindings to be replicated between the
			primary lwAFTR and the backup lwAFTR. When the primary lwAFTR fails,
			the backup lwAFTR has the necessary binding table entries to
			correctly forward subscriber traffic. In this mode, the internal
			hosts are not required to re-initiate the bindings with the external
			hosts. In lw4o6, as the number of binding states have been greatly
			reduced compared to DS-Lite, it is reasonable to adopt Hot Standby
			mode when there are only two lwAFTRs (a primary and a backup lwAFTR).
			However, if the number of lwAFTRs is larger than two, it is not
			scalable to deploy using hot standby mode since each two of the
			lwAFTRs should to syncronize the binding states.
	The lwAFTR can be deployed in a "centralized model" or a "distributed		4.4. Location of lwAFTRs in the Network
	model".
	In the "centralized model", the lwAFTR could be located at the higher		lwAFTR(s) can be deployed in a centralized or a distributed manner.
	place, e.g. at the exit of MAN, etc. Since the lwAFTR has good
	scalability and can handle numerous concurrent sessions, we recommend
	to adopt the "centralized model" for Lightweight 4over6 as it is
	cost-effective and easy to manage.
	In the "distributed model", lwAFTR is usually integrated with the		For a centralized deployment, the lwAFTR(s) are locacate in central
			aggregation points in the network, such as a core site, the exit
			point from a MAN etc. As the lwAFTR provides the gateway between the
			IPv6 and IPv4 networks, it allows single stack IPv6 to be deployed in
			the access part of the network.
			In a distributed deployment, lwAFTR function is integrated with the
	BRAS/SR. Since newly emerging customers might be distributed in the		BRAS/SR. Since newly emerging customers might be distributed in the
	whole Metro area, we have to deploy lwAFTR on all BRAS/SRs. This		whole Metro area, we have to deploy lwAFTR on all BRAS/SRs. This
	will cost a lot in the initial phase of the IPv6 transition period.		will cost a lot in the initial phase of the IPv6 transition period.
			This model also has the drawback of requiring both IPv4 and IPv6 to
			the BRAS/Service Router devices and so is unsuitable for providers
			wishing to build a single stack IPv6 only core.
	4.5. Port set algorithm consideration		4.5. Path Consistency Consideration
	If each lwB4 is given a set of ports, port randomization algorithm		In Lightweight 4over6, if the binding state is not syncronized among
	can only select port in the given port-set. This may introduce		multiple lwAFTRs, the lwAFTR in which the subscriber's binding state
	security risk because hackers can make a more predictable guess of		is stored should be exactly the one to service the subscriber.
	what port a subscriber may use. Therefore, non-continuous port set		Otherwise, there will be no match in the lwAFTR. This can be
	algorithms (e.g. as defined in [I-D.ietf-softwire-map]) can be used		achieved by using a unique IPv6 tunnel endpoint address and
	to improve security.		corresponding reachable public IPv4 customer prefix for each lwAFTR.
	4.6. Path Consistency Consideration		If multiple lwAFTRs are deployed for resilience or scalability, using
			the top-down provisioning model, all of the lwAFTRs in this cluster
			will share the same IPv6 tunnel endpoint and set of reachable
			prefixes. In this case, any packet arriving at any of the cluster
			members will be processed in the same way. However, it is worth
			considering using ECMP with flow-hashing so that a single customer's
			traffic will be processed by the same lwAFTR. This will reduce the
			change of packet re-ordering.
	In Lightweight 4over6, if the binding state is not syncronized among		In Lightweight 4over6, if the binding state is not syncronized among
	multiple lwAFTRs, the lwAFTR in which the subscriber's binding state		multiple lwAFTRs, the lwAFTR in which the subscriber's binding state
	is stored should be exactly the one to service the subscriber.		is stored should be exactly the one to service the subscriber.
	Otherwise, there will be no match in lwAFTR. This requires the		Otherwise, there will be no match in lwAFTR. This requires the
	provionsion packets (either using DHCPv4-over-DHCPv6 or PCP Port-set)		provionsion packets (either using DHCPv4-over-DHCPv6 or PCP Port-set)
	should arrive at the same lwAFTR as the subsquent IP-in-IP traffic.		should arrive at the same lwAFTR as the subsquent IP-in-IP traffic.
	If multiple lwAFTRs are using the same Tunnel End Point address and		If multiple lwAFTRs are using the same Tunnel End Point address and
	there are intermediate routers between lwB4 and lwAFTR, there might		there are intermediate routers between lwB4 and lwAFTR, there might
	be a problem when intermediate routers perform ECMP based on L4 hash		be a problem when intermediate routers perform ECMP based on L4 hash
	for the plain provionsion packets while doing L3 hash for subsequent		for the plain provionsion packets while doing L3 hash for subsequent
	IP-in-IP traffic. In this case, it is recommended that the		IP-in-IP traffic. In this case, it is recommended that the
	privioning packet is sent over IPv6 tunnel so that intermediate		provisioning packet is sent over IPv6 tunnel so that intermediate
	routers can only process ECMP using L3 hash.		routers can only process ECMP using L3 hash.
	5. lwB4 Deployment Consideration		5. lwB4 Deployment Considerations
	For lwB4 consideration, the DNS Deployment Considerations and B4		For the lwB4, the DNS Deployment Considerations and B4 Remote
	Remote Management in [RFC6908] can also be applied here. In this		Management in [RFC6908] can also be applied here. In this section,
	section, we only describe the considerations sepcific to Lightweight		only additional considerations relevant to lw4o6 are discussed.
	4over6.
	5.1. NAT traversal issue		5.1. NAT Traversal Issues
	In Lightweight 4over6, since the subscriber's source port will be		In lw4o6, as the subscriber's traffic source port will be restricted
	restricted to the port-set allocated from the provisioning system,		to the port-set allocated from the provisioning system, there will be
	this will have impact on some NAT traversal mechanisms. For example,		an impact on some NAT traversal mechanisms. For example, in UPnP
	in UPnP 1.0, the external port number which can be used by remote		1.0, the external port number that can be used by a remote peer is
	peer is selected by UPnP client in end host. If the client randomly		selected by a UPnP client in end host. If the client randomly
	selects a port number which is not in that valid port-set, the UPnP		selects a port number which dos not fall in that valid port-set, the
	process will fail. This is likely to happen because end-host does		UPnP process will fail.
	not know the port-set in lwB4. More detailed experimental results
	can be found in [I-D.deng-aplusp-experiment-results]. This problem		This is likely to happen because an end-host does not have knowledge
	will not exist in UPnP 2.0 because the UPnP client in the end-host		of the port-set which has been allocated to the lwB4. More detailed
	will negotiate the external port number with the server. Another way		experimental results can be found in
	is to implement a mechanism (e.g. [I-D.ietf-pcp-port-set], etc.) in		[I-D.deng-aplusp-experiment-results]. This problem will not exist in
	end host to fetch the port-set from lwB4. The UPnP client can then		UPnP 2.0 because the end-host's UPnP client in the will negotiate the
	select the port number within the port-set.		external port number with the server. Another way is to implement a
			mechanism (e.g. [RFC7753]) in end host to fetch the allocated port-
			set from the lwB4. The UPnP client can then select the port number
			within the port-set.
	5.2. Static Port Forwarding Configuration		5.2. Static Port Forwarding Configuration
	Currently, some external initiated applications rely on manual port		Currently, some externally initiated applications rely on manual
	configuration to reserve a port in the CPE. The restricted port-set		configuration to reserve a port in the CPE. The restricted port-set
	in lwB4 will also have impacts on manual port forwarding		used by the lwB4 may be problematic for manual port forwarding
	configuration. It is recommended that the port-set allocated from		configuration. It is recommended that the port-set allocated from
	the provioning system should be shown explicitly in the lwB4, which		the provioning system should be visible to the user (e.g. via the
	can be used as a hint for subscribers to add port forwarding mapping.		configuration interface of a HGW which implements the lwB4 function),
			which can be used as a hint for subscribers to add port forwarding
			mapping.
			It should also be noted that the well-known ports are not generally
			allocated to a lwB4, unless the client is being allocated a full IPv4
			address with no address sharing ([RFC7596], Section 5.1). If the
			user wishes to make a service running on an end-host using a well-
			known port externally accessible, it is necessary to configure the
			lwB4's port-forwarding to re-map the well-known port to a port taken
			from the allocated port-set.
	6. DS-Lite Compatibility Consideration		6. DS-Lite Compatibility Consideration
	Lightweight 4over6 can be either deployed all alone, or combined with		Lightweight 4over6 can be either deployed as a complete solution, or
	DS-Lite [RFC6333]. Since Lightweight 4over6 does not any have extra		in conjuction with DS-Lite. Since Lightweight 4over6 does not any
	requirement on IPv6 addressing, it can use use the same addressing		have extra requirement on IPv6 addressing, it can use use the same
	scheme with DS-Lite, together with routing policy, user management		addressing scheme with DS-Lite, together with routing policy, user
	policy, etc. Besides, the bottom-up model has quite similar		management policy, etc. Besides, the bottom-up model has quite
	requirement and workflow on the supporting system with DS-Lite.		similar requirement and workflow on the supporting system with DS-
	Therefore, it is suitable for operators to deploy incrementally in		Lite. Therefore, it is suitable for operators to deploy
	existing DS-Lite network		incrementally in existing DS-Lite network
	6.1. Case 1: Integrated Network Element with Lightweight 4over6 and DS-		6.1. Case 1: Integrated Network Element with Lightweight 4over6 and DS-
	Lite AFTR Scenario		Lite AFTR Scenario
	In this case, DS-Lite has been deployed in the network. Later in the		In this case, DS-Lite has been deployed in the network. Later in the
	deployment schedule, the operator decided to implement Lightweight		deployment schedule, the operator decided to implement Lightweight
	4over6 lwAFTR function in the same network element(depicted in		4over6 lwAFTR function in the same network element (depicted in
	Figure3). Therefore, the same network element needs to support both		Figure3, below). Therefore, the same network element needs to
	transition mechanisms.		support both transition mechanisms.
	There are two options to distinguish the traffic from two transition		There are two options to distinguish the traffic from two transition
	mechanisms.		mechanisms.
	The first one is to distinguish using the client's source IPv4		The first one is to distinguish using the client's source IPv4
	address. The IPv4 address from Lightweight 4over6 is public address		address. The IPv4 address from Lightweight 4over6 is public address
	as NAT has been done in the lwB4, and IPv4 address for DS-lite is		as NAT has been done in the lwB4, and IPv4 address for DS-lite is
	private address as NAT will be done on AFTR. When the network		private address as NAT will be done on AFTR. When the network
	element receives an encapsulated packet, it would de-capsulate packet		element receives an encapsulated packet, it would de-capsulate packet
	and apply the transition mechanism based on the IPv4 source address		and apply the transition mechanism based on the IPv4 source address
	skipping to change at page 12, line 47 ¶		skipping to change at page 13, line 4 ¶
	can use the same DHCPv6 option [RFC6334] with the same FQDN of the		can use the same DHCPv6 option [RFC6334] with the same FQDN of the
	AFTR and lwAFTR.		AFTR and lwAFTR.
	The second one is to distinguish using the destination's tunnel IPv6		The second one is to distinguish using the destination's tunnel IPv6
	address. One network element can run separated instances for		address. One network element can run separated instances for
	Lightweight 4over6 and DS-Lite with different tunnel addresses. Then		Lightweight 4over6 and DS-Lite with different tunnel addresses. Then
	B4 element and Lightweight 4over6 lwB4 can use the same DHCPv6 option		B4 element and Lightweight 4over6 lwB4 can use the same DHCPv6 option
	[RFC6334] with different FQDNs pointing to corresponding tunnel		[RFC6334] with different FQDNs pointing to corresponding tunnel
	addresses. This requires the supporting system should distinguish		addresses. This requires the supporting system should distinguish
	different types of users when assigning the FQDNs in DHCPv6 process.		different types of users when assigning the FQDNs in DHCPv6 process.
	Another option is to use a new DHCPv6 option
	[I-D.sun-softwire-lw4over6-dhcpv6] to discover lwAFTR's FQDN.		Another option is to use a new DHCPv6 option [RFC7598] to discover
			the lwAFTR's FQDN.
	+---------------+--------------|		+---------------+--------------|
	+ | |		+ | |
	+---------+ +------+---+ +--+--+ |		+---------+ +------+---+ +--+--+ |
	| Host | | LW 4over6| | | |		| Host | | LW 4over6| | | |
	| |--| lwB4 | ======-| BNG | === +-------------+ +-----------+		| |--| lwB4 | ======-| BNG | === +-------------+ +-----------+
	+---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 |		+---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 |
	|lwAFTR/ |---| Internet |		|lwAFTR/ |---| Internet |
	+---------+ +------+---+ +--+--+ |DS-Lite AFTR | | |		+---------+ +------+---+ +--+--+ |DS-Lite AFTR | | |
	| Host |--| DS-Lite | =======| | ====+-------------+ +-----------+		| Host |--| DS-Lite | =======| | ====+-------------+ +-----------+
	| | | B4 | | BNG | |		| | | B4 | | BNG | |
	+---------+ +----------+ +--|--+ |		+---------+ +----------+ +--|--+ |
	+ | |		+ | |
	+---------------+--------------+		+---------------+--------------+
	Figure 3 DS-Lite Coexistence scenario with Integrated AFTR		Figure 3 DS-Lite Coexistence scenario with Integrated AFTR
	6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR		6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR
	This is similar to Case 1. The difference is the lwAFTR and AFTR		This is similar to Case 1. The difference is the lwAFTR and AFTR
	functions won't be co-located in the same network element (depicted		functions won't be co-located in the same network element (depicted
	in Figure4). This use case decouples the functions to allow more		in Figure4). This use case decouples the functions to allow more
	flexible deployment. For example, an operator may deploy AFTR closer		flexible deployment. For example, an operator may deploy AFTR closer
	to the edge and lwAFTR closer to the core. Moreover, it does not		to the edge and lwAFTR closer to the core. Moreover, it does not
	require the network element to pre-configure with the CPE's IPv6		require the network element to pre-configure with the CPE's IPv6
	addresses. An operator can deploy more AFTR and lwAFTR at needed.		addresses. An operator can deploy more AFTR and lwAFTR at needed.
	However, this requires the B4 and lwB4 to discover the corresponding		However, this requires the B4 and lwB4 to discover the corresponding
	network element. In this case, B4 element and Lightweight 4over6		network element. In this case, B4 element and Lightweight 4over6
	lwB4 can still use [RFC6334] with different FQDNs pointing to		lwB4 can still use [RFC6334] with different FQDNs pointing to
	corresponding tunnel end-point addresses, and the supporting system		corresponding tunnel end-point addresses, and the supporting system
	should distinguish different types of users.		should distinguish different types of users.
	+---+---------------+-----------------|		+------------------+-----------------|
	+ | |		| | |
	+---------+ +------+---+ +------+-----+ |		+---------+ +------+---+ +------+-----+ |
	| Host | | LW 4over6| | BNG | |		| Host |__| LW 4over6| | BNG | |
	| |--| lwB4 | ======-|DS-Lite AFTR| === +------------+ +-----------+		| | | lwB4 |=======|DS-Lite AFTR|=====+------------+ +----------+
	+---------+ +----------+ +------+-----+ | LW 4over6 | | IPv4 |		+---------+ +----------+ +------+-----+ | lw4o6 | | IPv4 |
	| lwAFTR |---| Internet |		| lwAFTR |---| Internet |
	+---------+ +------+---+ +------+-----+ | | | |		+---------+ +------+---+ +------+-----+ | | | |
	| Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+		| Host |__| DS-Lite |=======| BNG |=====+------------+ +----------+
	| | | B4 | |DS-Lite AFTR| |		| | | B4 | |DS-Lite AFTR| |
	+---------+ +----------+ +------+-----+ |		+---------+ +----------+ +------+-----+ |
	+ | |		| | |
	+-------------------+-----------------+		+------------------+-----------------+
	Figure 4 DS-Lite Coexistence scenario with Seperated AFTR		Figure 4 DS-Lite Co-existence scenario with Seperated AFTR/lwAFTR
	7. Acknowledgement		7. Acknowledgements
	TBD		TBD
	8. References		8. References
	[I-D.bajko-pripaddrassign]		[I-D.bajko-pripaddrassign]
	Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,		Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
	"Port Restricted IP Address Assignment",		"Port Restricted IP Address Assignment", draft-bajko-
	draft-bajko-pripaddrassign-04 (work in progress),		pripaddrassign-04 (work in progress), April 2012.
	April 2012.
	[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-11		Architecture", draft-cui-softwire-b4-translated-ds-lite-11
	(work in progress), February 2013.		(work in progress), February 2013.
	[I-D.deng-aplusp-experiment-results]		[I-D.deng-aplusp-experiment-results]
	Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P		Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P
	in the provider's IPv6-only network",		in the provider's IPv6-only network", draft-deng-aplusp-
	draft-deng-aplusp-experiment-results-00 (work in		experiment-results-00 (work in progress), March 2011.
	progress), March 2011.
	[I-D.ietf-behave-ipfix-nat-logging]		[I-D.ietf-behave-ipfix-nat-logging]
	Sivakumar, S. and R. Penno, "IPFIX Information Elements		Sivakumar, S. and R. Penno, "IPFIX Information Elements
	for logging NAT Events",		for logging NAT Events", draft-ietf-behave-ipfix-nat-
	draft-ietf-behave-ipfix-nat-logging-13 (work in progress),		logging-13 (work in progress), January 2017.
	January 2017.
	[I-D.ietf-behave-syslog-nat-logging]		[I-D.ietf-behave-syslog-nat-logging]
	Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog		Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
	Format for NAT Logging",		Format for NAT Logging", draft-ietf-behave-syslog-nat-
	draft-ietf-behave-syslog-nat-logging-06 (work in		logging-06 (work in progress), January 2014.
	progress), January 2014.
	[I-D.ietf-dhc-dhcpv4-over-ipv6]		[I-D.ietf-dhc-dhcp4o6-saddr-opt]
	Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4		Farrer, I., Sun, Q., Cui, Y., and L. Sun, "DHCPv4 over
	over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-09		DHCPv6 Source Address Option", draft-ietf-dhc-dhcp4o6-
	(work in progress), April 2014.		saddr-opt-00 (work in progress), March 2017.
	[I-D.ietf-pcp-base]		[I-D.ietf-pcp-base]
	Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.		Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
	Selkirk, "Port Control Protocol (PCP)",		Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-
	draft-ietf-pcp-base-29 (work in progress), November 2012.		base-29 (work in progress), November 2012.
	[I-D.ietf-pcp-port-set]
	Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou,
	T., and S. Perreault, "Port Control Protocol (PCP)
	Extension for Port Set Allocation",
	draft-ietf-pcp-port-set-13 (work in progress),
	October 2015.
	[I-D.ietf-softwire-4rd]
	Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
	M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
	Solution (4rd)", draft-ietf-softwire-4rd-10 (work in
	progress), December 2014.
	[I-D.ietf-softwire-dslite-deployment]		[I-D.ietf-softwire-dslite-deployment]
	Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.		Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
	Boucadair, "Deployment Considerations for Dual-Stack		Boucadair, "Deployment Considerations for Dual-Stack
	Lite", draft-ietf-softwire-dslite-deployment-08 (work in		Lite", draft-ietf-softwire-dslite-deployment-08 (work in
	progress), January 2013.		progress), January 2013.
	[I-D.ietf-softwire-lw4over6]		[I-D.ietf-softwire-map-radius]
	Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and		Jiang, S., Fu, Y., Liu, B., Deacon, P., Xie, C., and T.
	I. Farrer, "Lightweight 4over6: An Extension to the DS-		Li, "RADIUS Attribute for Softwire Address plus Port based
	Lite Architecture", draft-ietf-softwire-lw4over6-13 (work		Mechanisms", draft-ietf-softwire-map-radius-12 (work in
	in progress), November 2014.		progress), May 2017.
	[I-D.ietf-softwire-map]		[I-D.ietf-softwire-yang]
	Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,		Sun, Q., Wang, H., Cui, Y., Farrer, I., Zoric, S.,
	Murakami, T., and T. Taylor, "Mapping of Address and Port		Boucadair, M., and R. Asati, "A YANG Data Model for IPv4-
	with Encapsulation (MAP)", draft-ietf-softwire-map-13		in-IPv6 Softwires", draft-ietf-softwire-yang-01 (work in
	(work in progress), March 2015.		progress), October 2016.
	[I-D.lee-softwire-lw4over6-failover]		[I-D.lee-softwire-lw4over6-failover]
	Lee, Y., Qiong, Q., and C. Liu, "Simple Failover Mechanism		Lee, Y., Qiong, Q., and C. Liu, "Simple Failover Mechanism
	for Lightweight 4over6",		for Lightweight 4over6", draft-lee-softwire-
	draft-lee-softwire-lw4over6-failover-01 (work in		lw4over6-failover-01 (work in progress), July 2013.
	progress), July 2013.
	[I-D.sun-softwire-lw4over6-dhcpv6]		[I-D.sun-softwire-lw4over6-dhcpv6]
	Xie, C., Qiong, Q., Lee, Y., Tsou, T., and P. Wu, "Dynamic		Xie, C., Qiong, Q., Lee, Y., Tsou, T., and P. Wu, "Dynamic
	Host Configuration Protocol for IPv6 (DHCPv6) Option for		Host Configuration Protocol for IPv6 (DHCPv6) Option for
	Lightweight 4over6", draft-sun-softwire-lw4over6-dhcpv6-00		Lightweight 4over6", draft-sun-softwire-lw4over6-dhcpv6-00
	(work in progress), July 2013.		(work in progress), July 2013.
	[I-D.zhou-dime-4over6-provisioning]		[I-D.zhou-dime-4over6-provisioning]
	Zhou, C., Taylor, T., Qiong, Q., and M. Boucadair,		Zhou, C., Taylor, T., Qiong, Q., and M. Boucadair,
	"Attribute-Value Pairs For Provisioning Customer Equipment		"Attribute-Value Pairs For Provisioning Customer Equipment
	Supporting IPv4-Over-IPv6 Transitional Solutions",		Supporting IPv4-Over-IPv6 Transitional Solutions", draft-
	draft-zhou-dime-4over6-provisioning-05 (work in progress),		zhou-dime-4over6-provisioning-05 (work in progress),
	September 2014.		September 2014.
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,		Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	DOI 10.17487/RFC6052, October 2010,		DOI 10.17487/RFC6052, October 2010,
	<http://www.rfc-editor.org/info/rfc6052>.		<http://www.rfc-editor.org/info/rfc6052>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	skipping to change at page 17, line 25 ¶		skipping to change at page 16, line 30 ¶
	[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, DOI 10.17487/RFC6333, August 2011,		Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
	<http://www.rfc-editor.org/info/rfc6333>.		<http://www.rfc-editor.org/info/rfc6333>.
	[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration		[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
	Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",		Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
	RFC 6334, DOI 10.17487/RFC6334, August 2011,		RFC 6334, DOI 10.17487/RFC6334, August 2011,
	<http://www.rfc-editor.org/info/rfc6334>.		<http://www.rfc-editor.org/info/rfc6334>.
			[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
			the IPv4 Address Shortage", RFC 6346,
			DOI 10.17487/RFC6346, August 2011,
			<http://www.rfc-editor.org/info/rfc6346>.
	[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and		[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
	T. Tsou, "Huawei Port Range Configuration Options for PPP		T. Tsou, "Huawei Port Range Configuration Options for PPP
	IP Control Protocol (IPCP)", RFC 6431, DOI 10.17487/		IP Control Protocol (IPCP)", RFC 6431,
	RFC6431, November 2011,		DOI 10.17487/RFC6431, November 2011,
	<http://www.rfc-editor.org/info/rfc6431>.		<http://www.rfc-editor.org/info/rfc6431>.
	[RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.		[RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
	Boucadair, "Deployment Considerations for Dual-Stack		Boucadair, "Deployment Considerations for Dual-Stack
	Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013,		Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013,
	<http://www.rfc-editor.org/info/rfc6908>.		<http://www.rfc-editor.org/info/rfc6908>.
			[RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
			IPv4-over-IPv6 Access Network", RFC 7040,
			DOI 10.17487/RFC7040, November 2013,
			<http://www.rfc-editor.org/info/rfc7040>.
	[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.		[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
	Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",		Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
	RFC 7341, DOI 10.17487/RFC7341, August 2014,		RFC 7341, DOI 10.17487/RFC7341, August 2014,
	<http://www.rfc-editor.org/info/rfc7341>.		<http://www.rfc-editor.org/info/rfc7341>.
			[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
			Farrer, "Lightweight 4over6: An Extension to the Dual-
			Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
			July 2015, <http://www.rfc-editor.org/info/rfc7596>.
			[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
			Murakami, T., and T. Taylor, Ed., "Mapping of Address and
			Port with Encapsulation (MAP-E)", RFC 7597,
			DOI 10.17487/RFC7597, July 2015,
			<http://www.rfc-editor.org/info/rfc7597>.
			[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
			W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
			Configuration of Softwire Address and Port-Mapped
			Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
			<http://www.rfc-editor.org/info/rfc7598>.
			[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
			and M. Chen, "IPv4 Residual Deployment via IPv6 - A
			Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
			July 2015, <http://www.rfc-editor.org/info/rfc7600>.
	[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.		[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
	Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",		Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
	RFC 7618, DOI 10.17487/RFC7618, August 2015,		RFC 7618, DOI 10.17487/RFC7618, August 2015,
	<http://www.rfc-editor.org/info/rfc7618>.		<http://www.rfc-editor.org/info/rfc7618>.
	1. China Telecom Experimental Result		[RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
			and S. Perreault, "Port Control Protocol (PCP) Extension
			for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753,
			February 2016, <http://www.rfc-editor.org/info/rfc7753>.
			Appendix A. China Telecom Experimental Results
	We have deployed Lightweight 4over6 in our operational network of		We have deployed Lightweight 4over6 in our operational network of
	HuNan province, China. It is designed for broadband access network,		HuNan province, China. It is designed for broadband access network,
	and different versions of lwB4 have been implemented including a		and different versions of the lwB4 function have been implemented
	linksys box, a software client for windows XP, vista and Windows 7.		including a Linksys device, a software client for Windows XP, Windows
			Vista and Windows 7.
	It can be integrated with existing dial-up mechanisms such as PPPoE,		It can be integrated with existing dial-up mechanisms such as PPPoE,
	etc. The major objectives listed below aimed to verify the		etc. The major objectives listed below aimed to verify the
	functionality and performance of Lightweight 4over6:		functionality and performance of Lightweight 4over6:
	o Verify how to deploy Lightweight 4over6 in a practical network.		o Verify how to deploy Lightweight 4over6 in a practical network.
	o Verify the impact of applications with Lightweight 4over6.		o Verify the impact of applications with Lightweight 4over6.
	o Verify the performance of Lightweight 4over6.		o Verify the performance of Lightweight 4over6.
	1.1. Experimental Environment		A.1. Experimental Environment
	The network topology for this experiment is depicted in Figure 5.		The network topology for this experiment is depicted in Figure 5.
	+--------+		+--------+
	+-----+ +-------+ | Syslog |		+-----+ +-------+ | Syslog |
	|Host1+--+lwB4 |----+ | Server |		|Host1+--+lwB4 |----+ | Server |
	+-----+ +-------+ | +---+----+ ---------		+-----+ +-------+ | +---+----+ ---------
	| /------\ | // \\		| /------\ | // \\
	| // \\ | / \		| // \\ | / \
	+-----+ +-------+ +-+--+ | IPv6 | +---+----+ | |		+-----+ +-------+ +-+--+ | IPv6 | +---+----+ | |
	|Host2+--|lwB4 |----+BRAS+--| Network |---|lwAFTR +-+ IPv4 Internet +		|Host2+--|lwB4 |----+BRAS+--| Network |---|lwAFTR +-+ IPv4 Internet +
	+-----+ +-------+ +-+--+ \\ // +--------+ | |		+-----+ +-------+ +-+--+ \\ // +--------+ | |
	| \--+---/ (PCP Server) \ /		| \--+---/ (PCP Server) \ /
	| | \\ //		| | \\ //
	+-----+ +-------+ | | ---------		+-----+ +-------+ | | ---------
	|Host3+--+lwB4 +----+ |		|Host3+--+lwB4 +----+ |
	+-----+ +-------+ | ---------		+-----+ +-------+ | ---------
	| // \\		| // \\
	| / \		| / \
	| | |		| | |
	+--------------------+ IPv6 Internet +		+--------------------+ IPv6 Internet +
	| |		| |
	\ /		\ /
	\\ //		\\ //
	---------		---------
	Figure 5 China Telecom Lightweight 4over6 experiment topology		Figure 5 China Telecom Lightweight 4over6 Experiment Topology
	In this deployment model, lwAFTR is co-located with a extended PCP		In this deployment model, the lwAFTR is co-located with an extended
	server to assign restricted IPv4 address and port set for lwB4. It		PCP server to assign port-restricted IPv4 addresses and port-sets to
	also triggers subscriber-based logging event to a centrilized syslog		lwB4s. It also triggers subscriber-based logging event to a
	server. IPv6 address pools for subscribers have been distributed to		centrilized syslog server. IPv6 address pools for subscribers have
	BRASs for configuration, while the public available IPv4 address		been distributed to BRASs for configuration, while the available
	pools are configured by the centralized lwAFTR with a default address		public IPv4 address pools are configured by the centralized lwAFTR
	sharing ratio. It is rather flexible for IPv6 addressing and		with a default address sharing ratio. It is rather flexible for IPv6
	routing, and there is little impact on existing IPv6 architecture.		addressing and routing, and there is little impact on existing IPv6
			architecture.
	In our experiment, lwB4 will firstly get its IPv6 address and		In our experiment, lwB4 will firstly get its IPv6 address and
	delegated prefix through PPPoE, and then initiate a PCP-extended		delegated prefix through PPPoE, and then initiate a PCP-extended
	request to get public IPv4 address and its valid port set. The		request to get public IPv4 address and its valid port set. The
	lwAFTR will thus create a subscriber-based state accordingly, and		lwAFTR will thus create a subscriber-based state accordingly, and
	notify syslog server with {IPv6 address, IPv4 address, port set,		notify the syslog server with {IPv6 address, IPv4 address, port set,
	timestamp}.		timestamp}.
	1.2. Experimental Results		A.2. Experimental Results
	In our trial, we mainly focused on application test and performance		In our trial, we mainly focused on application and performance tests.
	test. The applications have widely include web, email, Instant		The applications tested include web (HTTP/HTTPS), email, instant
	Message, ftp, telnet, SSH, video, Video Camera, P2P, online game,		messaging, FTP, telnet, SSH, video, Video Camera, P2P, online gaming,
	voip and so on. For performance test, we have measured the		and VoIP.
	parameters of concurrent session numbers and throughput performance.
			For the performance tests, we measured the number of concurrent
			session and throughput performance.
	The experimental results are listed as follows:		The experimental results are listed as follows:
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| Application Type | Test Result |Port Number Occupation |		| Application Type | Test Result |Port Number Occupation |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| Web | ok | normal websites: 10~20|		| Web | OK | normal websites: 10~20|
	| | IE, Firefox, Chrome | Ajex Flash webs: 30~40|		| | IE, Firefox, Chrome | Ajex Flash webs: 30~40|
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| Video | ok, web based or | 30~40 |		| Video | ok, web based or | 30~40 |
	| | client based | |		| | client based | |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| Instant Message | ok | |		| Instant Message | OK | |
	| | QQ, MSN, gtalk, skype| 8~20 |		| | QQ, MSN, gtalk, skype| 8~20 |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| P2P | ok | lower speed: 20~600 |		| P2P | OK | lower speed: 20~600 |
	| |utorrent,emule,xunlei | (per seed) |		| |utorrent,emule,xunlei | (per seed) |
	| | | higher speed: 150~300 |		| | | higher speed: 150~300 |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| FTP | need ALG for active | 2 |		| FTP | need ALG for active | 2 |
	| | mode, flashxp | |		| | mode, flashxp | |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| SSH, TELNET | ok |1 for SSH, 3 for telnet|		| SSH, TELNET | OK |1 for SSH, 3 for telnet|
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	| online game | ok for QQ, flash game| 20~40 |		| online game | OK for QQ, flash game| 20~40 |
	+--------------------+----------------------+-----------------------+		+--------------------+----------------------+-----------------------+
	Figure 6 China Telecom 4over6 experimental result		Figure 6 China Telecom Lightweight 4over6 Experiment Results
	The performance test for lwAFTR is taken on a normal PC. Due to
			The performance tests for the lwAFTR are taken using a PC. Due to
	limitations of the PC hardware, the overall throughput is limited to		limitations of the PC hardware, the overall throughput is limited to
	around 800 Mbps. However, it can still support more than one hundred		around 800 Mbps. However, it can still support more than one hundred
	million concurrent sessions.		million concurrent sessions.
	1.3. Conclusions		A.3. Conclusions
	From the experiment, we can have the following conclusions:		From the experiment, we reached the following conclusions:
	o Lightweight 4over6 has good scalability. As it is a lightweight		o Lightweight 4over6 has good scalability. As it is a lightweight
	solution which only maintains per-subscription state information,		solution that only maintains per-subscription state information,
	it can easily support a large amount of concurrent subscribers.		it can easily support a large amount of concurrent subscribers.
	o Lightweight 4over6 can be deployed rapidly. There is no		o Lightweight 4over6 can be deployed rapidly. No modifications to
	modification to existing addressing and routing system in our		the existing addressing and routing system in our operational
	operational network. And it is simple to achieve traffic logging.		network was necessary. Logging of customer address allocations
			was easy to implement.
	o Lightweight 4over6 can support a majority of current IPv4		o Lightweight 4over6 can support the majority of current IPv4
	applications.		applications commonly in use.
	2. Tsinghua University Experimental Result		Appendix B. Tsinghua University Experimental Result
	Lightweight 4over6 has also been deployed in the campus of Tsinghua		Lightweight 4over6 has been deployed in the campus of Tsinghua
	University, China. We use DHCPv4 over DHCPv6 [RFC7341] for the		University, China. DHCPv4o6 [RFC7341] is used for dynamically
	dynamic provisioning of lwB4's IPv4 address and port set [RFC7618].		provisioning the lwB4's IPv4 address and port set [RFC7618].
	We deployed wireless APs for Lightweight 4over6, covering a large		Wireless APs for Lightweight 4over6, were deployed, covering a large
	portion of the campus, allowing mobile devices to connect to the		portion of the campus, allowing mobile devices to connect to the
	lwB4. We also deployed lwB4 gateway in some of our buildings so PCs		lwB4. We also deployed a lwB4 gateway in some of our buildings so
	could connect directly to the lwB4. Users could access the IPv4		that end device could connect directly to the lwB4. Users access the
	Internet through the CNGI IPv6 Network.		IPv4 Internet through the China Next Generation Internet (CNGI) IPv6
			Network.
	2.1. Experimental Environment		B.1. Experimental Environment
	The network topology for this experiment is depicted in Figure 7.		The network topology for this experiment is depicted in Figure 7.
	+-----+ ------- ---------		+-----+ ------- ---------
	|Host1+---+ / \ // \\		|Host1+---+ / \ // \\
	+-----+ | // \\ / \		+-----+ | // \\ / \
	+-----+ | +--------+ | CNGI IPv6 | +--------+ | |		+-----+ | +--------+ | CNGI IPv6 | +--------+ | |
	|Host2+---+--+lwB4(AP)+--+--| Network |--+ lwAFTR +---+ IPv4 Internet +		|Host2+---+--+lwB4(AP)+--+--| Network |--+ lwAFTR +---+ IPv4 Internet +
	+-----+ | +--------+ | \\ // +--------+ | |		+-----+ | +--------+ | \\ // +--------+ | |
	+-----+ | | \ / (DHCP4o6 Server) \ /		+-----+ | | \ / (DHCP4o6 Server) \ /
	|Host3+---+ | --+---- \\ //		|Host3+---+ | --+---- \\ //
	+-----+ | | ---------		+-----+ | | ---------
	| |		| |
	+-----+ | | ---------		+-----+ | | ---------
	|Host4+---+ | | // \\		|Host4+---+ | | // \\
	+-----+ | +------+ | | / \		+-----+ | +------+ | | / \
	+---+lwB4 +--+ | | |		+---+lwB4 +---+ | | |
	+-----+ | +------+ +-----------------------+ IPv6 Internet +		+-----+ | +------+ +-----------------------+ IPv6 Internet +
	|Host5+---+ | |		|Host5+---+ | |
	+-----+ \ /		+-----+ \ /
	\\ //		\\ //
	---------		---------
	Figure 7 Tsinghua University Lightweight 4over6 experiment topology		Figure 7 Tsinghua University Lightweight 4over6 Experiment Topology
	In this deployment model, lwAFTR is co-located with a DHCP4o6 server		In this deployment model, the lwAFTR is co-located with a DHCP4o6
	to assign restricted IPv4 address and port set for lwB4. lwAFTR		server to assign port-restricted IPv4 addresses and port-sets to the
	listens to all DHCPv4 over DHCPv6 messages generated or received by		lwB4. The lwAFTR snoops the DHCPv4 over DHCPv6 messages generated or
	the DHCP4o6 server and updates its binding table through valid		received by the DHCP4o6 server and updates its binding table
	messages.		accordingly.
	In our experiment, the lwB4 gets its IPv6 address through static		In our experiment, the lwB4 receives its IPv6 address through static
	configuration or dynamic configuration. It will then send a request		or dynamic configuration. It then sends a DHCP4o6 request to the
	to the lwAFTR device to get the public IPv4 address and its valid		lwAFTR device to get the public IPv4 address and valid port-set. The
	port set. The lwAFTR will add the IPv6 address, IPv4 address, and		lwAFTR will add the IPv6 address, IPv4 address, and port-set
	port set information of the lwB4 into its binding table.		information of the lwB4 into its binding table.
	2.2. Experimental Results		B.2. Experimental Results
	In our experiment, we tested the performence of various applications,		In the Tsinghua University experiment, the performance of various
	including web, video, p2p, ping, tracert, telnet, SSH, email. online		applications were tested including web (HTTP/HTTPS), email, instant
	storage, instant message, online gaming, online payment and so on.		messaging, FTP, telnet, SSH, video, Video Camera, P2P, online gaming,
	We also tested different terminal devices including PC, laptop		and VoIP. We also tested different terminal devices including PC/
	computer, and cell phone. These include devices using different		laptop computers, and cell phone. These devices used different
	operating systems, including Windows 7, MacOS, Android, and IOS.		operating systems, including Windows 7, MacOS, Android, and Apple
			IOS.
	The experimental results are listed as follows:		The experimental results were as follows:
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	|Application Type | Test Applications | Test Subjects |Result|		|Application Type | Test Applications | Test Subjects |Result|
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	| Web | IE, Chrome, Sougou |Browse websites, | OK |		| Web | IE, Chrome, Sougou |Browse websites, | OK |
	| | |download files | |		| | |download files | |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	| Video | Youku, pptv, qqlive |VOD, live video | OK |		| Video | Youku, pptv, qqlive |VOD, live video | OK |
	| |(Web based,client based)| | |		| |(Web based,client based)| | |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	skipping to change at page 22, line 44 ¶		skipping to change at page 22, line 32 ¶
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	| Cloud storage | Baidu Cloud |Upload/download files| OK |		| Cloud storage | Baidu Cloud |Upload/download files| OK |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	|Instant messaging| Skype, QQ |Send/receive messages| OK |		|Instant messaging| Skype, QQ |Send/receive messages| OK |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	|Online gaming | QQ game |Enter game | OK |		|Online gaming | QQ game |Enter game | OK |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	|Online payment | JD, Taobao |Complete payment | OK |		|Online payment | JD, Taobao |Complete payment | OK |
	+-----------------+------------------------+---------------------+------+		+-----------------+------------------------+---------------------+------+
	Figure 8 Tsinghua University Lightweight 4over6 experimental result		Figure 8 Tsinghua University Lightweight 4over6 experimental result
	2.3. Conclusions		B.3. Conclusion
	Lightweight 4over6 supports the majority of current IPv4 applications		Lightweight 4over6 supports the majority of current IPv4 applications
	and services. The user experience of using Lightweight 4over6 is no		and services. The user experience of using Lightweight 4over6 is no
	different from using the native IPv4 network. It can satisfy the		different from using the native IPv4 network. It can satisfy the
	IPv4 network service demands of IPv6 network users.		IPv4 network service demands of IPv6 network users.
	Authors' Addresses		Authors' Addresses
	Qiong Sun		Qiong Sun
	China Telecom		China Telecom
	skipping to change at line 923 ¶		skipping to change at page 23, line 36 ¶
	Email: fibrib@gmail.com		Email: fibrib@gmail.com
	Tianxiang Li		Tianxiang Li
	Tsinghua University		Tsinghua University
	Beijing 100084		Beijing 100084
	P.R.China		P.R.China
	Phone: +86-10-6278-5822		Phone: +86-10-6278-5822
	Email: peter416733@gmail.com		Email: peter416733@gmail.com
			Ian Farrer
			Deutsche Telekom AG
			Bonn 53227
			Germany
			Email: ian.farrer@telekom.de
End of changes. 113 change blocks.
	427 lines changed or deleted		550 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/