idnits 2.17.1 draft-ietf-softwire-lightweight-4over6-deployment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 56 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2017) is 2649 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-dhc-dhcpv4-over-dhcpv6' is mentioned on line 237, but not defined == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'I-D.cui-softwire-b4-translated-ds-lite' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv4-over-ipv6' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pcp-base' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dslite-deployment' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC6431' is defined on line 647, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft C. Xie 4 Intended status: Informational China Telecom 5 Expires: July 29, 2017 Y. Lee 6 Comcast 7 M. Chen 8 FreeBit 9 T. Li 10 Tsinghua University 11 January 25, 2017 13 Deployment Considerations for Lightweight 4over6 14 draft-ietf-softwire-lightweight-4over6-deployment-00 16 Abstract 18 Lightweight 4over6 is a mechanism which moves the translation 19 function from tunnel lwAFTR (AFTR) to lwB4s (B4s), and hence reduces 20 the mapping scale on the lwAFTR to per-customer level. This document 21 discusses various deployment models of Lightweight 4over6. It also 22 describes the deployment considerations and applicability of the 23 Lightweight 4over6 architecture. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 29, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overall Deployment Considerations . . . . . . . . . . . . . . 6 62 3.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 6 63 3.2. Port-set Management . . . . . . . . . . . . . . . . . . . 6 64 3.3. lwAFTR Discovery . . . . . . . . . . . . . . . . . . . . . 7 65 3.4. Impacts on Accouting . . . . . . . . . . . . . . . . . . . 7 66 4. lwAFTR Deployment Consideration . . . . . . . . . . . . . . . 8 67 4.1. Logging at the lwAFTR . . . . . . . . . . . . . . . . . . 8 68 4.2. MTU and Fragmentation Considerations . . . . . . . . . . . 8 69 4.3. Reliability Considerations of lwAFTR . . . . . . . . . . . 8 70 4.4. Placement of AFTR . . . . . . . . . . . . . . . . . . . . 9 71 4.5. Port set algorithm consideration . . . . . . . . . . . . . 9 72 4.6. Path Consistency Consideration . . . . . . . . . . . . . . 9 73 5. lwB4 Deployment Consideration . . . . . . . . . . . . . . . . 11 74 5.1. NAT traversal issue . . . . . . . . . . . . . . . . . . . 11 75 5.2. Static Port Forwarding Configuration . . . . . . . . . . . 11 76 6. DS-Lite Compatibility Consideration . . . . . . . . . . . . . 12 77 6.1. Case 1: Integrated Network Element with Lightweight 78 4over6 and DS-Lite AFTR Scenario . . . . . . . . . . . . . 12 79 6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR . 13 80 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Appendix 1. China Telecom Experimental Result . . . . . . . . . . 18 83 1.1. Experimental Environment . . . . . . . . . . . . . . . . . 18 84 1.2. Experimental Results . . . . . . . . . . . . . . . . . . . 19 85 1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 20 86 Appendix 2. Tsinghua University Experimental Result . . . . . . . 21 87 2.1. Experimental Environment . . . . . . . . . . . . . . . . . 21 88 2.2. Experimental Results . . . . . . . . . . . . . . . . . . . 22 89 2.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to 95 DS-Lite which simplifies the AFTR module [RFC6333] with distributed 96 NAT function among B4 elements. The lwB4 in Lightweight 4over6 is 97 provisioned with an IPv6 address, an IPv4 address and a port-set. It 98 performs NAPT on end user's packets with the provisioned IPv4 address 99 and port-set. IPv4 packets are forwarded between the lwB4 and the 100 lwAFTR over a Softwire using IPv4-in-IPv6 encapsulation. The lwAFTR 101 maintains one mapping entry per subscriber with the IPv6 address, 102 IPv4 address and port-set. Therefore, this extension removes the 103 NAT44 module from the AFTR and replaces the session-based NAT table 104 to a per-subscriber based mapping table. This should relax the 105 requirement to create dynamic session-based log entries. This 106 mechanism preserves the dynamic feature of IPv4/IPv6 address binding 107 as in DS-Lite, so it has no coupling between IPv6 address and IPv4 108 address/port-set as any full stateless solution ([RFC6052] or 109 [I-D.ietf-softwire-map]) requires. This document discusses 110 deployment models of Lightweight 4over6. It also describes the 111 deployment considerations and applicability of the Lightweight 4over6 112 architecture. 114 Terminology of this document follows the definitions and 115 abbreviations of [I-D.ietf-softwire-lw4over6]. 117 2. Deployment Model 119 Lightweight 4over6 is suitable for operators who would like to free 120 any correlation of the IPv6 address with IPv4 address and port-set 121 (or port-range). In comparison to full stateless solutions like MAP 122 [I-D.ietf-softwire-map] and 4rd [I-D.ietf-softwire-4rd], Lightweight 123 4over6 frees address planning of IPv6 delegation for CPE from mapping 124 rule administration and management in the network. Thus, IPv6 125 addressing is completely flexible to fit other deployment 126 requirements, e.g., auto-configuration, service classification, user 127 management, QoS support, etc. The philosophy here is that bits of 128 IPv6 address should be left for IPv6 usage first. 130 Lightweight 4over6 can be deployed in a residential network (depicted 131 in Figure1). In this scenario, a lwB4 would acquire an IPv4 address 132 and a port-set after a successful user authentication process and 133 IPv6 provisioning process. Then, it establishes an IPv4-in-IPv6 134 softwire using the IPv6 address to deliver IPv4 services to its 135 connected host via the lwAFTR in the network. The lwB4 can act as a 136 CPE, or software located in the host. The lwAFTR supports 137 Lightweight 4over6 which keeps the mapping between lwB4's IPv6 138 address and its allocated IPv4 address + port set. The supporting 139 system may keep the binding information as well for logging and user 140 management. 142 +---------------+ 143 | Supporting | 144 | System | 145 +-------+-------+ 146 | 147 +---------------+--------------| 148 | | | 149 +---------+ +------+---+ +--+--+ | 150 | Host | | lwB4 | | | | 151 | |--| | ======-| BNG | === +---------+ +-----------+ 152 +---------+ +----------+ +--|--+ | | | IPv4 | 153 | lwAFTR |---| Internet | 154 +---------+ +------+---+ +--+--+ | | | | 155 | Host |--| lwB4 | =======| | ====+---------+ +-----------+ 156 | | | | | BNG | | 157 +---------+ +----------+ +--|--+ | 158 + | | 159 +---------------+--------------+ 161 Figure 1 Deployment Model 163 There are two deployment models in practice: one is called bottom-up 164 and the other is top-down. In bottom-up model, after port-restricted 165 IPv4 address is allocated to a given subscriber, the lwAFTR will 166 report mapping records to the supporting system on creating a binding 167 for traffic logging if necessary. Operators may use 168 [I-D.ietf-behave-syslog-nat-logging] or 169 [I-D.ietf-behave-ipfix-nat-logging] to report the port set allocated 170 by lwAFTR. In this way, the lwAFTR can determine the binding by its 171 own and there is little impact on existing network architecture. In 172 top-down model, the Supporting system should firstly determine the 173 binding information for each subscriber and then synchronize it with 174 the lwAFTR. With this method, one binding record can be easily 175 synchronized with multiple lwAFTRs and stateless failover can be 176 achieved. However, new mechanism (e.g. 177 [I-D.zhou-dime-4over6-provisioning]) needs to be introduced to notify 178 each individual binding record between the Supporting system and the 179 lwAFTR. 181 Lightweight 4over6 can also be deployed in a campus or enterprise 182 network, (depicted in Figure2). In this scenario, a lwB4 acts as a 183 wireless AP and is connected to a number of hosts. The lwB4 first 184 acquire the IPv4 address and port-set information, then it 185 establishes an IPv4-in-IPv6 softwire using the IPv6 address to 186 deliver IPv4 services to its connected host via the lwAFTR in the 187 network. A network management system could be used to receive 188 statistic information of the network equipments, such as the binding 189 table, network load, and connected device. NETCONF[RFC6241] could be 190 used for syncronising lwB4's IPv6 address and its allocated IPv4 191 address + port set with the lwAFTR. The network management system 192 may keep the binding information as well for logging and user 193 management. 195 +-------------------+ 196 | Network Management| 197 | System | 198 +---------+---------+ 199 | 200 +---------------+--------------| 201 | | 202 +---------+ | | 203 | Host | | | 204 | |--+ +----------+ +---------+ +-----------+ 205 +---------+ | | | | | | IPv4 | 206 + - + lwB4 | ============== | lwAFTR |---| Internet | 207 +---------+ | | | | | | | 208 | Host |--+ +----------+ +---------+ +-----------+ 209 | | 210 +---------+ 212 Figure 2 Deployment Model 214 3. Overall Deployment Considerations 216 3.1. Addressing and Routing 218 In Lightweight 4over6, there is no inter-dependency between IPv4 and 219 IPv6 addressing schemes. IPv4 address pools are configured 220 centralized in lwAFTR for IPv6 subscribers. These IPv4 prefix must 221 advertise to IPv4 Internet accordingly. 223 For IPv6 addressing and routing, there are no additional addressing 224 and routing requirements. The existing IPv6 address assignment and 225 routing announcement should not be affected. For example, in PPPoE 226 scenario, a CPE could obtain a prefix via prefix delegation 227 procedure, and the hosts behind CPE would get its own IPv6 addresses 228 within the prefix through SLAAC or DHCPv6 statefully. This IPv6 229 address assignment procedure has nothing to do with restricted IPv4 230 address allocation. 232 3.2. Port-set Management 234 In Lightweight 4over6, each lwB4 will get its restricted IPv4 address 235 and a port-set after successful user authentication process and IPv6 236 provisioning process. This port-set assignment can been achieved by 237 DHCPv4-over-DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and PCP 238 [I-D.ietf-pcp-port-set]. 240 Operator may use DHCPv4 to provision IPv4 address to the lwB4. In a 241 typical deployment, the DHCP server is a centralized DHCP server and 242 lwAFTR is the DHCP relay agent to relay the dhcp messages to the 243 server over unicast. Rarely DHCP server will collocate with the 244 lwAFTR to provision IPv4 resources to the lwB4. 246 Operator may also use PCP Port-set Option to provision IPv4 address 247 and port-set to the lwB4. In a typical deployment, PCP server will 248 collocate with lwAFTR, and the subscriber's binding can be determined 249 by lwAFTR. The PCP request should be sent to the lwAFTR's tunnel 250 end-point address. It is not common that PCP server will be 251 centralized deployed in which the lwAFTR is the PCP proxy to relay 252 PCP requests. 254 It is also possible that subscriber's binding is determined in AAA 255 server. In this case, the BNGs will embed with a DHCPv4-over-DHCPv6 256 server function which allows them to locally handle any DHCPv4-over- 257 DHCPv6 requests initiated by hosts. The AAA server will pass the 258 subscriber's binding to a BNG using the AAA attribute in [I-D.sun- 259 softwire-lw4over6-radext] and in turn populates the mapping of the 260 lwB4. 262 Some operators may offer different service level agreements (SLA) to 263 users that some users may require more ports then others. In this 264 deployment scenario, the operator can implement differentiated 265 policies in provisioning system specified to a user's lwB4 or a group 266 of lwB4s to allocate a certain range of port-set. The lwAFTR may 267 also run multiple instances with different port-set sizes to build 268 the mapping table. 270 3.3. lwAFTR Discovery 272 A Lightweight 4over6 lwB4 must discover the lwAFTR's IPv6 address 273 before offering any IPv4 services. This IPv6 address can be learned 274 through an out-of-band channel, static configuration, or dynamic 275 configuration. In practice, Lightweight 4over6 lwB4 can use the same 276 DHCPv6 option [RFC6334]to discover the FQDN of the lwAFTR. 278 When Lightweight 4over6 is deployed in the same place with DS-Lite, 279 either different FQDNs can be configured for Lightweight 4over6 and 280 DS-Lite separately or different DHCPv6 options can be used for 281 Lightweight 4over6 [I-D.sun-softwire-lw4over6-dhcpv6] and DS-Lite. 282 More detailed considerations on DS-Lite compatibility will be 283 discussed in Section6. 285 3.4. Impacts on Accouting 287 In Lightweight 4over6, the accounting impact due to the tunneling 288 protocol is the same with DS-Lite (see section 6.2 of [RFC6908]). 289 However, since in Lightweight 4over6, the IPv4 service is only 290 available after port-set allocation, if operators will regard IPv4 291 service as a on-demand value-added service, e.g. IPv6 connectivity 292 is offered by default, while IPv4 connectivity will be offered untill 293 a subscriber requires, etc., IPv4 service accounting should start 294 after port-set allocation has completely. 296 4. lwAFTR Deployment Consideration 298 As Lightweight 4over6 is an extension to DS-Lite, both technologies 299 share similar deployment considerations. For example: Interface 300 consideration, Lawful Intercept Considerations, Blacklisting a shared 301 IPv4 Address, AFTR's Policies, AFTR Impacts on Accounting Process, 302 etc., in [RFC6908] can also be applied here. This document only 303 discusses new considerations specific to Lightweight 4over6. 305 4.1. Logging at the lwAFTR 307 In Lightweight 4over6, operators only log one entry per subscriber. 308 The log should include subscriber's IPv6 address used for the 309 softwire, the public IPv4 address and the port-set. The port set 310 algorithm implemented in Lightweight 4over6 lwAFTR should be 311 synchronized with the one implemented in logging system. For 312 example, if contiguous port set algorithm is adopted in the lwAFTR, 313 the same algorithm should also been applied to the logging system. 315 Since the mapping in lwAFTR does not contain destination-specific 316 information, operator should be aware that they will not be able to 317 have destination-specific log. 319 4.2. MTU and Fragmentation Considerations 321 As Lightweight 4over6 is also a tunneling protocol, the same 322 consideration regarding to the fragmentation and reassembly in DS- 323 Lite [RFC6908] can also be applied. The only difference is that NAT 324 functionality has been removed to lwB4 from lwAFTR in Lightweight 325 4over6. Therefore, on receiving an IPv4 fragmented packet after 326 decapsulation in the lwB4, the lwB4 should further re-assemble the 327 packets before doing NAT since the transport protocol information is 328 only available in the first fragment. 330 4.3. Reliability Considerations of lwAFTR 332 Operators may deploy multiple lwAFTRs for robustness, reliability, 333 and load balancing. In Lightweight 4over6, subscriber to IPv4 and 334 port-set mapping must be pre-provisioned in the lwAFTR before 335 providing IPv4 serives. For redundancy, the backup lwAFTR must 336 either have the subscriber mapping already provisioned or notify the 337 lwB4 to create a new mapping in the backup lwAFTR. The first option 338 can be considered as Hot Standby mode, which requires state 339 syncronization between multiple lwAFTRs. In Hot Standby mode, the 340 bindings are replicated on-the-fly from the Primary lwAFTR to the 341 Backup lwAFTR. When the Primary lwAFTR fails, the Backup lwAFTR will 342 take over all the existing established sessions. In this mode, the 343 internal hosts are not required to re-initiate the bindings with the 344 external hosts. In Lightweight 4over6, since the number of mapping 345 states has been greatly reduced compared to DS-Lite, it is reasonable 346 to adopt Hot Standby mode when there are only two lwAFTRs (one for 347 Primary lwAFTR and one for Backup lwAFTR). However, if the number of 348 lwAFTRs is larger than two, it is not scalable to deploy Hot Standby 349 mode since each two of the lwAFTRs should to syncronize the binding 350 states. 352 The second option is to use Cold Standby mode which does not require 353 a Backup Standby lwAFTR to synchronize binding states. In failover, 354 the lwAFTR has to notify the lwB4 to create a new binding, or fetch 355 the binding by itself. [I-D.lee-softwire-lw4over6-failover] 356 describes these two approaches for simple Cold Standby mode. For 357 most deployment scenarios, we believe that Cold Standby mode should 358 be sufficient enough and is thus recommended. 360 4.4. Placement of AFTR 362 The lwAFTR can be deployed in a "centralized model" or a "distributed 363 model". 365 In the "centralized model", the lwAFTR could be located at the higher 366 place, e.g. at the exit of MAN, etc. Since the lwAFTR has good 367 scalability and can handle numerous concurrent sessions, we recommend 368 to adopt the "centralized model" for Lightweight 4over6 as it is 369 cost-effective and easy to manage. 371 In the "distributed model", lwAFTR is usually integrated with the 372 BRAS/SR. Since newly emerging customers might be distributed in the 373 whole Metro area, we have to deploy lwAFTR on all BRAS/SRs. This 374 will cost a lot in the initial phase of the IPv6 transition period. 376 4.5. Port set algorithm consideration 378 If each lwB4 is given a set of ports, port randomization algorithm 379 can only select port in the given port-set. This may introduce 380 security risk because hackers can make a more predictable guess of 381 what port a subscriber may use. Therefore, non-continuous port set 382 algorithms (e.g. as defined in [I-D.ietf-softwire-map]) can be used 383 to improve security. 385 4.6. Path Consistency Consideration 387 In Lightweight 4over6, if the binding state is not syncronized among 388 multiple lwAFTRs, the lwAFTR in which the subscriber's binding state 389 is stored should be exactly the one to service the subscriber. 390 Otherwise, there will be no match in lwAFTR. This requires the 391 provionsion packets (either using DHCPv4-over-DHCPv6 or PCP Port-set) 392 should arrive at the same lwAFTR as the subsquent IP-in-IP traffic. 393 If multiple lwAFTRs are using the same Tunnel End Point address and 394 there are intermediate routers between lwB4 and lwAFTR, there might 395 be a problem when intermediate routers perform ECMP based on L4 hash 396 for the plain provionsion packets while doing L3 hash for subsequent 397 IP-in-IP traffic. In this case, it is recommended that the 398 privioning packet is sent over IPv6 tunnel so that intermediate 399 routers can only process ECMP using L3 hash. 401 5. lwB4 Deployment Consideration 403 For lwB4 consideration, the DNS Deployment Considerations and B4 404 Remote Management in [RFC6908] can also be applied here. In this 405 section, we only describe the considerations sepcific to Lightweight 406 4over6. 408 5.1. NAT traversal issue 410 In Lightweight 4over6, since the subscriber's source port will be 411 restricted to the port-set allocated from the provisioning system, 412 this will have impact on some NAT traversal mechanisms. For example, 413 in UPnP 1.0, the external port number which can be used by remote 414 peer is selected by UPnP client in end host. If the client randomly 415 selects a port number which is not in that valid port-set, the UPnP 416 process will fail. This is likely to happen because end-host does 417 not know the port-set in lwB4. More detailed experimental results 418 can be found in [I-D.deng-aplusp-experiment-results]. This problem 419 will not exist in UPnP 2.0 because the UPnP client in the end-host 420 will negotiate the external port number with the server. Another way 421 is to implement a mechanism (e.g. [I-D.ietf-pcp-port-set], etc.) in 422 end host to fetch the port-set from lwB4. The UPnP client can then 423 select the port number within the port-set. 425 5.2. Static Port Forwarding Configuration 427 Currently, some external initiated applications rely on manual port 428 configuration to reserve a port in the CPE. The restricted port-set 429 in lwB4 will also have impacts on manual port forwarding 430 configuration. It is recommended that the port-set allocated from 431 the provioning system should be shown explicitly in the lwB4, which 432 can be used as a hint for subscribers to add port forwarding mapping. 434 6. DS-Lite Compatibility Consideration 436 Lightweight 4over6 can be either deployed all alone, or combined with 437 DS-Lite [RFC6333]. Since Lightweight 4over6 does not any have extra 438 requirement on IPv6 addressing, it can use use the same addressing 439 scheme with DS-Lite, together with routing policy, user management 440 policy, etc. Besides, the bottom-up model has quite similar 441 requirement and workflow on the supporting system with DS-Lite. 442 Therefore, it is suitable for operators to deploy incrementally in 443 existing DS-Lite network 445 6.1. Case 1: Integrated Network Element with Lightweight 4over6 and DS- 446 Lite AFTR Scenario 448 In this case, DS-Lite has been deployed in the network. Later in the 449 deployment schedule, the operator decided to implement Lightweight 450 4over6 lwAFTR function in the same network element(depicted in 451 Figure3). Therefore, the same network element needs to support both 452 transition mechanisms. 454 There are two options to distinguish the traffic from two transition 455 mechanisms. 457 The first one is to distinguish using the client's source IPv4 458 address. The IPv4 address from Lightweight 4over6 is public address 459 as NAT has been done in the lwB4, and IPv4 address for DS-lite is 460 private address as NAT will be done on AFTR. When the network 461 element receives an encapsulated packet, it would de-capsulate packet 462 and apply the transition mechanism based on the IPv4 source address 463 in the packet. This requires the network element to examine every 464 packet and may introduce significant extra load to the network 465 element. However, both the B4 element and Lightweight 4over6 lwB4 466 can use the same DHCPv6 option [RFC6334] with the same FQDN of the 467 AFTR and lwAFTR. 469 The second one is to distinguish using the destination's tunnel IPv6 470 address. One network element can run separated instances for 471 Lightweight 4over6 and DS-Lite with different tunnel addresses. Then 472 B4 element and Lightweight 4over6 lwB4 can use the same DHCPv6 option 473 [RFC6334] with different FQDNs pointing to corresponding tunnel 474 addresses. This requires the supporting system should distinguish 475 different types of users when assigning the FQDNs in DHCPv6 process. 476 Another option is to use a new DHCPv6 option 477 [I-D.sun-softwire-lw4over6-dhcpv6] to discover lwAFTR's FQDN. 479 +---------------+--------------| 480 + | | 481 +---------+ +------+---+ +--+--+ | 482 | Host | | LW 4over6| | | | 483 | |--| lwB4 | ======-| BNG | === +-------------+ +-----------+ 484 +---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 | 485 |lwAFTR/ |---| Internet | 486 +---------+ +------+---+ +--+--+ |DS-Lite AFTR | | | 487 | Host |--| DS-Lite | =======| | ====+-------------+ +-----------+ 488 | | | B4 | | BNG | | 489 +---------+ +----------+ +--|--+ | 490 + | | 491 +---------------+--------------+ 493 Figure 3 DS-Lite Coexistence scenario with Integrated AFTR 495 6.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR 497 This is similar to Case 1. The difference is the lwAFTR and AFTR 498 functions won't be co-located in the same network element (depicted 499 in Figure4). This use case decouples the functions to allow more 500 flexible deployment. For example, an operator may deploy AFTR closer 501 to the edge and lwAFTR closer to the core. Moreover, it does not 502 require the network element to pre-configure with the CPE's IPv6 503 addresses. An operator can deploy more AFTR and lwAFTR at needed. 504 However, this requires the B4 and lwB4 to discover the corresponding 505 network element. In this case, B4 element and Lightweight 4over6 506 lwB4 can still use [RFC6334] with different FQDNs pointing to 507 corresponding tunnel end-point addresses, and the supporting system 508 should distinguish different types of users. 510 +---+---------------+-----------------| 511 + | | 512 +---------+ +------+---+ +------+-----+ | 513 | Host | | LW 4over6| | BNG | | 514 | |--| lwB4 | ======-|DS-Lite AFTR| === +------------+ +-----------+ 515 +---------+ +----------+ +------+-----+ | LW 4over6 | | IPv4 | 516 | lwAFTR |---| Internet | 517 +---------+ +------+---+ +------+-----+ | | | | 518 | Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+ 519 | | | B4 | |DS-Lite AFTR| | 520 +---------+ +----------+ +------+-----+ | 521 + | | 522 +-------------------+-----------------+ 524 Figure 4 DS-Lite Coexistence scenario with Seperated AFTR 526 7. Acknowledgement 528 TBD 530 8. References 532 [I-D.bajko-pripaddrassign] 533 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 534 "Port Restricted IP Address Assignment", 535 draft-bajko-pripaddrassign-04 (work in progress), 536 April 2012. 538 [I-D.cui-softwire-b4-translated-ds-lite] 539 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 540 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 541 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 542 (work in progress), February 2013. 544 [I-D.deng-aplusp-experiment-results] 545 Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P 546 in the provider's IPv6-only network", 547 draft-deng-aplusp-experiment-results-00 (work in 548 progress), March 2011. 550 [I-D.ietf-behave-ipfix-nat-logging] 551 Sivakumar, S. and R. Penno, "IPFIX Information Elements 552 for logging NAT Events", 553 draft-ietf-behave-ipfix-nat-logging-13 (work in progress), 554 January 2017. 556 [I-D.ietf-behave-syslog-nat-logging] 557 Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog 558 Format for NAT Logging", 559 draft-ietf-behave-syslog-nat-logging-06 (work in 560 progress), January 2014. 562 [I-D.ietf-dhc-dhcpv4-over-ipv6] 563 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 564 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-09 565 (work in progress), April 2014. 567 [I-D.ietf-pcp-base] 568 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 569 Selkirk, "Port Control Protocol (PCP)", 570 draft-ietf-pcp-base-29 (work in progress), November 2012. 572 [I-D.ietf-pcp-port-set] 573 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 574 T., and S. Perreault, "Port Control Protocol (PCP) 575 Extension for Port Set Allocation", 576 draft-ietf-pcp-port-set-13 (work in progress), 577 October 2015. 579 [I-D.ietf-softwire-4rd] 580 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 581 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 582 Solution (4rd)", draft-ietf-softwire-4rd-10 (work in 583 progress), December 2014. 585 [I-D.ietf-softwire-dslite-deployment] 586 Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 587 Boucadair, "Deployment Considerations for Dual-Stack 588 Lite", draft-ietf-softwire-dslite-deployment-08 (work in 589 progress), January 2013. 591 [I-D.ietf-softwire-lw4over6] 592 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 593 I. Farrer, "Lightweight 4over6: An Extension to the DS- 594 Lite Architecture", draft-ietf-softwire-lw4over6-13 (work 595 in progress), November 2014. 597 [I-D.ietf-softwire-map] 598 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 599 Murakami, T., and T. Taylor, "Mapping of Address and Port 600 with Encapsulation (MAP)", draft-ietf-softwire-map-13 601 (work in progress), March 2015. 603 [I-D.lee-softwire-lw4over6-failover] 604 Lee, Y., Qiong, Q., and C. Liu, "Simple Failover Mechanism 605 for Lightweight 4over6", 606 draft-lee-softwire-lw4over6-failover-01 (work in 607 progress), July 2013. 609 [I-D.sun-softwire-lw4over6-dhcpv6] 610 Xie, C., Qiong, Q., Lee, Y., Tsou, T., and P. Wu, "Dynamic 611 Host Configuration Protocol for IPv6 (DHCPv6) Option for 612 Lightweight 4over6", draft-sun-softwire-lw4over6-dhcpv6-00 613 (work in progress), July 2013. 615 [I-D.zhou-dime-4over6-provisioning] 616 Zhou, C., Taylor, T., Qiong, Q., and M. Boucadair, 617 "Attribute-Value Pairs For Provisioning Customer Equipment 618 Supporting IPv4-Over-IPv6 Transitional Solutions", 619 draft-zhou-dime-4over6-provisioning-05 (work in progress), 620 September 2014. 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 624 RFC2119, March 1997, 625 . 627 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 628 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 629 DOI 10.17487/RFC6052, October 2010, 630 . 632 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 633 and A. Bierman, Ed., "Network Configuration Protocol 634 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 635 . 637 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 638 Stack Lite Broadband Deployments Following IPv4 639 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 640 . 642 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 643 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 644 RFC 6334, DOI 10.17487/RFC6334, August 2011, 645 . 647 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 648 T. Tsou, "Huawei Port Range Configuration Options for PPP 649 IP Control Protocol (IPCP)", RFC 6431, DOI 10.17487/ 650 RFC6431, November 2011, 651 . 653 [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 654 Boucadair, "Deployment Considerations for Dual-Stack 655 Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013, 656 . 658 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 659 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 660 RFC 7341, DOI 10.17487/RFC7341, August 2014, 661 . 663 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 664 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 665 RFC 7618, DOI 10.17487/RFC7618, August 2015, 666 . 668 1. China Telecom Experimental Result 670 We have deployed Lightweight 4over6 in our operational network of 671 HuNan province, China. It is designed for broadband access network, 672 and different versions of lwB4 have been implemented including a 673 linksys box, a software client for windows XP, vista and Windows 7. 674 It can be integrated with existing dial-up mechanisms such as PPPoE, 675 etc. The major objectives listed below aimed to verify the 676 functionality and performance of Lightweight 4over6: 678 o Verify how to deploy Lightweight 4over6 in a practical network. 680 o Verify the impact of applications with Lightweight 4over6. 682 o Verify the performance of Lightweight 4over6. 684 1.1. Experimental Environment 686 The network topology for this experiment is depicted in Figure 5. 688 +--------+ 689 +-----+ +-------+ | Syslog | 690 |Host1+--+lwB4 |----+ | Server | 691 +-----+ +-------+ | +---+----+ --------- 692 | /------\ | // \\ 693 | // \\ | / \ 694 +-----+ +-------+ +-+--+ | IPv6 | +---+----+ | | 695 |Host2+--|lwB4 |----+BRAS+--| Network |---|lwAFTR +-+ IPv4 Internet + 696 +-----+ +-------+ +-+--+ \\ // +--------+ | | 697 | \--+---/ (PCP Server) \ / 698 | | \\ // 699 +-----+ +-------+ | | --------- 700 |Host3+--+lwB4 +----+ | 701 +-----+ +-------+ | --------- 702 | // \\ 703 | / \ 704 | | | 705 +--------------------+ IPv6 Internet + 706 | | 707 \ / 708 \\ // 709 --------- 711 Figure 5 China Telecom Lightweight 4over6 experiment topology 713 In this deployment model, lwAFTR is co-located with a extended PCP 714 server to assign restricted IPv4 address and port set for lwB4. It 715 also triggers subscriber-based logging event to a centrilized syslog 716 server. IPv6 address pools for subscribers have been distributed to 717 BRASs for configuration, while the public available IPv4 address 718 pools are configured by the centralized lwAFTR with a default address 719 sharing ratio. It is rather flexible for IPv6 addressing and 720 routing, and there is little impact on existing IPv6 architecture. 722 In our experiment, lwB4 will firstly get its IPv6 address and 723 delegated prefix through PPPoE, and then initiate a PCP-extended 724 request to get public IPv4 address and its valid port set. The 725 lwAFTR will thus create a subscriber-based state accordingly, and 726 notify syslog server with {IPv6 address, IPv4 address, port set, 727 timestamp}. 729 1.2. Experimental Results 731 In our trial, we mainly focused on application test and performance 732 test. The applications have widely include web, email, Instant 733 Message, ftp, telnet, SSH, video, Video Camera, P2P, online game, 734 voip and so on. For performance test, we have measured the 735 parameters of concurrent session numbers and throughput performance. 737 The experimental results are listed as follows: 739 +--------------------+----------------------+-----------------------+ 740 | Application Type | Test Result |Port Number Occupation | 741 +--------------------+----------------------+-----------------------+ 742 | Web | ok | normal websites: 10~20| 743 | | IE, Firefox, Chrome | Ajex Flash webs: 30~40| 744 +--------------------+----------------------+-----------------------+ 745 | Video | ok, web based or | 30~40 | 746 | | client based | | 747 +--------------------+----------------------+-----------------------+ 748 | Instant Message | ok | | 749 | | QQ, MSN, gtalk, skype| 8~20 | 750 +--------------------+----------------------+-----------------------+ 751 | P2P | ok | lower speed: 20~600 | 752 | |utorrent,emule,xunlei | (per seed) | 753 | | | higher speed: 150~300 | 754 +--------------------+----------------------+-----------------------+ 755 | FTP | need ALG for active | 2 | 756 | | mode, flashxp | | 757 +--------------------+----------------------+-----------------------+ 758 | SSH, TELNET | ok |1 for SSH, 3 for telnet| 759 +--------------------+----------------------+-----------------------+ 760 | online game | ok for QQ, flash game| 20~40 | 761 +--------------------+----------------------+-----------------------+ 763 Figure 6 China Telecom 4over6 experimental result 764 The performance test for lwAFTR is taken on a normal PC. Due to 765 limitations of the PC hardware, the overall throughput is limited to 766 around 800 Mbps. However, it can still support more than one hundred 767 million concurrent sessions. 769 1.3. Conclusions 771 From the experiment, we can have the following conclusions: 773 o Lightweight 4over6 has good scalability. As it is a lightweight 774 solution which only maintains per-subscription state information, 775 it can easily support a large amount of concurrent subscribers. 777 o Lightweight 4over6 can be deployed rapidly. There is no 778 modification to existing addressing and routing system in our 779 operational network. And it is simple to achieve traffic logging. 781 o Lightweight 4over6 can support a majority of current IPv4 782 applications. 784 2. Tsinghua University Experimental Result 786 Lightweight 4over6 has also been deployed in the campus of Tsinghua 787 University, China. We use DHCPv4 over DHCPv6 [RFC7341] for the 788 dynamic provisioning of lwB4's IPv4 address and port set [RFC7618]. 789 We deployed wireless APs for Lightweight 4over6, covering a large 790 portion of the campus, allowing mobile devices to connect to the 791 lwB4. We also deployed lwB4 gateway in some of our buildings so PCs 792 could connect directly to the lwB4. Users could access the IPv4 793 Internet through the CNGI IPv6 Network. 795 2.1. Experimental Environment 797 The network topology for this experiment is depicted in Figure 7. 799 +-----+ ------- --------- 800 |Host1+---+ / \ // \\ 801 +-----+ | // \\ / \ 802 +-----+ | +--------+ | CNGI IPv6 | +--------+ | | 803 |Host2+---+--+lwB4(AP)+--+--| Network |--+ lwAFTR +---+ IPv4 Internet + 804 +-----+ | +--------+ | \\ // +--------+ | | 805 +-----+ | | \ / (DHCP4o6 Server) \ / 806 |Host3+---+ | --+---- \\ // 807 +-----+ | | --------- 808 | | 809 +-----+ | | --------- 810 |Host4+---+ | | // \\ 811 +-----+ | +------+ | | / \ 812 +---+lwB4 +--+ | | | 813 +-----+ | +------+ +-----------------------+ IPv6 Internet + 814 |Host5+---+ | | 815 +-----+ \ / 816 \\ // 817 --------- 819 Figure 7 Tsinghua University Lightweight 4over6 experiment topology 821 In this deployment model, lwAFTR is co-located with a DHCP4o6 server 822 to assign restricted IPv4 address and port set for lwB4. lwAFTR 823 listens to all DHCPv4 over DHCPv6 messages generated or received by 824 the DHCP4o6 server and updates its binding table through valid 825 messages. 827 In our experiment, the lwB4 gets its IPv6 address through static 828 configuration or dynamic configuration. It will then send a request 829 to the lwAFTR device to get the public IPv4 address and its valid 830 port set. The lwAFTR will add the IPv6 address, IPv4 address, and 831 port set information of the lwB4 into its binding table. 833 2.2. Experimental Results 835 In our experiment, we tested the performence of various applications, 836 including web, video, p2p, ping, tracert, telnet, SSH, email. online 837 storage, instant message, online gaming, online payment and so on. 838 We also tested different terminal devices including PC, laptop 839 computer, and cell phone. These include devices using different 840 operating systems, including Windows 7, MacOS, Android, and IOS. 842 The experimental results are listed as follows: 844 +-----------------+------------------------+---------------------+------+ 845 |Application Type | Test Applications | Test Subjects |Result| 846 +-----------------+------------------------+---------------------+------+ 847 | Web | IE, Chrome, Sougou |Browse websites, | OK | 848 | | |download files | | 849 +-----------------+------------------------+---------------------+------+ 850 | Video | Youku, pptv, qqlive |VOD, live video | OK | 851 | |(Web based,client based)| | | 852 +-----------------+------------------------+---------------------+------+ 853 | P2P | Bittorrent, xunlei |Download files | OK | 854 +-----------------+------------------------+---------------------+------+ 855 | Ping/tracert | Command line |Ping/tracert URL | OK | 856 +-----------------+------------------------+---------------------+------+ 857 | TELNET/SSH | Putty, secureCRT |Telnet/SSH login | OK | 858 +-----------------+------------------------+---------------------+------+ 859 | Email | 126, QQ, hotmail |Send/receive email | OK | 860 | |(Web based,client based)| | | 861 +-----------------+------------------------+---------------------+------+ 862 | Cloud storage | Baidu Cloud |Upload/download files| OK | 863 +-----------------+------------------------+---------------------+------+ 864 |Instant messaging| Skype, QQ |Send/receive messages| OK | 865 +-----------------+------------------------+---------------------+------+ 866 |Online gaming | QQ game |Enter game | OK | 867 +-----------------+------------------------+---------------------+------+ 868 |Online payment | JD, Taobao |Complete payment | OK | 869 +-----------------+------------------------+---------------------+------+ 871 Figure 8 Tsinghua University Lightweight 4over6 experimental result 873 2.3. Conclusions 875 Lightweight 4over6 supports the majority of current IPv4 applications 876 and services. The user experience of using Lightweight 4over6 is no 877 different from using the native IPv4 network. It can satisfy the 878 IPv4 network service demands of IPv6 network users. 880 Authors' Addresses 882 Qiong Sun 883 China Telecom 884 Room 708, No.118, Xizhimennei Street 885 Beijing 100035 886 P.R.China 888 Phone: +86-10-58552936> 889 Email: sunqiong@ctbri.com.cn 891 Chongfeng Xie 892 China Telecom 893 Room 708, No.118, Xizhimennei Street 894 Beijing 100035 895 P.R.China 897 Phone: +86-10-58552116> 898 Email: xiechf@ctbri.com.cn 900 Yiu L. Lee 901 Comcast 902 One Comcast Center 903 Philadelphia, PA 19103 904 USA 906 Email: yiu_lee@cable.comcast.com 908 Maoke Chen 909 FreeBit Co., Ltd. 910 13F E-space Tower, Maruyama-cho 3-6 911 Shibuya-ku, Tokyo 150-0044 912 Japan 914 Email: fibrib@gmail.com 916 Tianxiang Li 917 Tsinghua University 918 Beijing 100084 919 P.R.China 921 Phone: +86-10-6278-5822 922 Email: peter416733@gmail.com