idnits 2.17.1 draft-sun-softwire-lightweigh-4over6-deployment-04.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 13 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 14, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-dhc-dhcpv4-over-dhcpv6' is mentioned on line 205, but not defined == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'I-D.cui-softwire-b4-translated-ds-lite' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-dhcpv4-over-ipv6' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pcp-base' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dslite-deployment' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC6431' is defined on line 604, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-deng-aplusp-experiment-results (ref. 'I-D.deng-aplusp-experiment-results') == Outdated reference: A later version (-13) exists of draft-ietf-behave-ipfix-nat-logging-00 == Outdated reference: A later version (-06) exists of draft-ietf-behave-syslog-nat-logging-01 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-06 ** Downref: Normative reference to an Informational draft: draft-ietf-dhc-dhcpv4-over-ipv6 (ref. 'I-D.ietf-dhc-dhcpv4-over-ipv6') == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-softwire-4rd (ref. 'I-D.ietf-softwire-4rd') ** Downref: Normative reference to an Informational draft: draft-ietf-softwire-dslite-deployment (ref. 'I-D.ietf-softwire-dslite-deployment') == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-00 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 == Outdated reference: A later version (-01) exists of draft-lee-softwire-lw4over6-failover-00 ** Downref: Normative reference to an Informational draft: draft-lee-softwire-lw4over6-failover (ref. 'I-D.lee-softwire-lw4over6-failover') == Outdated reference: A later version (-05) exists of draft-zhou-dime-4over6-provisioning-00 ** Downref: Normative reference to an Informational RFC: RFC 6431 ** Downref: Normative reference to an Informational RFC: RFC 6908 Summary: 11 errors (**), 0 flaws (~~), 18 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: Standards Track China Telecom 5 Expires: January 15, 2014 Y. Lee 6 Comcast 7 M. Chen 8 FreeBit 9 July 14, 2013 11 Deployment Considerations for Lightweight 4over6 12 draft-sun-softwire-lightweigh-4over6-deployment-04 14 Abstract 16 Lightweight 4over6 is a mechanism which moves the translation 17 function from tunnel lwAFTR (AFTR) to lwB4s (B4s), and hence reduces 18 the mapping scale on the lwAFTR to per-customer level. This document 19 discusses various deployment models of Lightweight 4over6. It also 20 describes the deployment considerations and applicability of the 21 Lightweight 4over6 architecture. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 15, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Deployment Model . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overall Deployment Considerations . . . . . . . . . . . . . . 7 61 4.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 7 62 4.2. Port-set Management . . . . . . . . . . . . . . . . . . . 7 63 4.3. lwAFTR Discovery . . . . . . . . . . . . . . . . . . . . . 8 64 4.4. Impacts on Accouting . . . . . . . . . . . . . . . . . . . 8 65 5. lwAFTR Deployment Consideration . . . . . . . . . . . . . . . 9 66 5.1. Logging at the lwAFTR . . . . . . . . . . . . . . . . . . 9 67 5.2. MTU and Fragmentation Considerations . . . . . . . . . . . 9 68 5.3. Reliability Considerations of lwAFTR . . . . . . . . . . . 9 69 5.4. Placement of AFTR . . . . . . . . . . . . . . . . . . . . 10 70 5.5. Port set algorithm consideration . . . . . . . . . . . . . 10 71 5.6. Path Consistency Consideration . . . . . . . . . . . . . . 10 72 6. lwB4 Deployment Consideration . . . . . . . . . . . . . . . . 12 73 6.1. NAT traversal issue . . . . . . . . . . . . . . . . . . . 12 74 6.2. Static Port Forwarding Configuration . . . . . . . . . . . 12 75 7. DS-Lite Compatibility Consideration . . . . . . . . . . . . . 13 76 7.1. Case 1: Integrated Network Element with Lightweight 77 4over6 and DS-Lite AFTR Scenario . . . . . . . . . . . . . 13 78 7.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR . 14 79 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Appendix 1. Appendix:Experimental Result . . . . . . . . . . . . 19 82 1.1. Experimental environment . . . . . . . . . . . . . . . . . 19 83 1.2. Experimental results . . . . . . . . . . . . . . . . . . . 20 84 1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to 90 DS-Lite which simplifies the AFTR module [RFC6333] with distributed 91 NAT function among B4 elements. The lwB4 in Lightweight 4over6 is 92 provisioned with an IPv6 address, an IPv4 address and a port-set. It 93 performs NAPT on end user's packets with the provisioned IPv4 address 94 and port-set. IPv4 packets are forwarded between the lwB4 and the 95 lwAFTR over a Softwire using IPv4-in-IPv6 encapsulation. The lwAFTR 96 maintains one mapping entry per subscriber with the IPv6 address, 97 IPv4 address and port-set. Therefore, this extension removes the 98 NAT44 module from the AFTR and replaces the session-based NAT table 99 to a per-subscriber based mapping table. This should relax the 100 requirement to create dynamic session-based log entries. This 101 mechanism preserves the dynamic feature of IPv4/IPv6 address binding 102 as in DS-Lite, so it has no coupling between IPv6 address and IPv4 103 address/port-set as any full stateless solution ([RFC6052] or 104 [I-D.ietf-softwire-map]) requires. This document discusses 105 deployment models of Lightweight 4over6. It also describes the 106 deployment considerations and applicability of the Lightweight 4over6 107 architecture. 109 Terminology of this document follows the definitions and 110 abbreviations of [I-D.ietf-softwire-lw4over6]. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Deployment Model 120 Lightweight 4over6 is suitable for operators who would like to free 121 any correlation of the IPv6 address with IPv4 address and port-set 122 (or port-range). In comparison to full stateless solutions like MAP 123 [I-D.ietf-softwire-map] and 4rd [I-D.ietf-softwire-4rd], Lightweight 124 4over6 frees address planning of IPv6 delegation for CPE from mapping 125 rule administration and management in the network. Thus, IPv6 126 addressing is completely flexible to fit other deployment 127 requirements, e.g., auto-configuration, service classification, user 128 management, QoS support, etc. The philosophy here is that bits of 129 IPv6 address should be left for IPv6 usage first. 131 Lightweight 4over6 can be deployed in a residential network (depicted 132 in Figure1). In this scenario, a lwB4 would acquire an IPv4 address 133 and a port-set after a successful user authentication process and 134 IPv6 provisioning process. Then, it establishes an IPv4-in-IPv6 135 softwire using the IPv6 address to deliver IPv4 services to its 136 connected host via the lwAFTR in the network. The lwB4 can act as a 137 CPE, or software located in the host. The lwAFTR supports 138 Lightweight 4over6 which keeps the mapping between lwB4's IPv6 139 address and its allocated IPv4 address + port set. The supporting 140 system may keep the binding information as well for logging and user 141 management. 143 +---------------+ 144 | Supporting | 145 | System | 146 +-------+-------+ 147 | 148 +---------------+--------------| 149 | | | 150 +---------+ +------+---+ +--+--+ | 151 | Host | | lwB4 | | | | 152 | |--| | ======-| BNG | === +---------+ +-----------+ 153 +---------+ +----------+ +--|--+ | | | IPv4 | 154 | lwAFTR |---| Internet | 155 +---------+ +------+---+ +--+--+ | | | | 156 | Host |--| lwB4 | =======| | ====+---------+ +-----------+ 157 | | | | | BNG | | 158 +---------+ +----------+ +--|--+ | 159 + | | 160 +---------------+--------------+ 162 Figure 1 Deployment Model 164 There are two deployment models in practice: one is called bottom-up 165 and the other is top-down. In bottom-up model, after port-restricted 166 IPv4 address is allocated to a given subscriber, the lwAFTR will 167 report mapping records to the supporting system on creating a binding 168 for traffic logging if necessary. Operators may use 169 [I-D.ietf-behave-syslog-nat-logging] or 170 [I-D.ietf-behave-ipfix-nat-logging] to report the port set allocated 171 by lwAFTR. In this way, the lwAFTR can determine the binding by its 172 own and there is little impact on existing network architecture. In 173 top-down model, the Supporting system should firstly determine the 174 binding information for each subscriber and then synchronize it with 175 the lwAFTR. With this method, one binding record can be easily 176 synchronized with multiple lwAFTRs and stateless failover can be 177 achieved. However, new mechanism (e.g. 178 [I-D.zhou-dime-4over6-provisioning]) needs to be introduced to notify 179 each individual binding record between the Supporting system and the 180 lwAFTR. 182 4. Overall Deployment Considerations 184 4.1. Addressing and Routing 186 In Lightweight 4over6, there is no inter-dependency between IPv4 and 187 IPv6 addressing schemes. IPv4 address pools are configured 188 centralized in lwAFTR for IPv6 subscribers. These IPv4 prefix must 189 advertise to IPv4 Internet accordingly. 191 For IPv6 addressing and routing, there are no additional addressing 192 and routing requirements. The existing IPv6 address assignment and 193 routing announcement should not be affected. For example, in PPPoE 194 scenario, a CPE could obtain a prefix via prefix delegation 195 procedure, and the hosts behind CPE would get its own IPv6 addresses 196 within the prefix through SLAAC or DHCPv6 statefully. This IPv6 197 address assignment procedure has nothing to do with restricted IPv4 198 address allocation. 200 4.2. Port-set Management 202 In Lightweight 4over6, each lwB4 will get its restricted IPv4 address 203 and a port-set after successful user authentication process and IPv6 204 provisioning process. This port-set assignment can been achieved by 205 DHCPv4-over-DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and PCP 206 [I-D.ietf-pcp-port-set]. 208 Operator may use DHCPv4 to provision IPv4 address to the lwB4. In a 209 typical deployment, the DHCP server is a centralized DHCP server and 210 lwAFTR is the DHCP relay agent to relay the dhcp messages to the 211 server over unicast. Rarely DHCP server will collocate with the 212 lwAFTR to provision IPv4 resources to the lwB4. 214 Operator may also use PCP Port-set Option to provision IPv4 address 215 and port-set to the lwB4. In a typical deployment, PCP server will 216 collocate with lwAFTR, and the subscriber's binding can be determined 217 by lwAFTR. The PCP request should be sent to the lwAFTR's tunnel 218 end-point address. It is not common that PCP server will be 219 centralized deployed in which the lwAFTR is the PCP proxy to relay 220 PCP requests. 222 It is also possible that subscriber's binding is determined in AAA 223 server. In this case, the BNGs will embed with a DHCPv4-over-DHCPv6 224 server function which allows them to locally handle any DHCPv4-over- 225 DHCPv6 requests initiated by hosts. The AAA server will pass the 226 subscriber's binding to a BNG using the AAA attribute in [I-D.sun- 227 softwire-lw4over6-radext] and in turn populates the mapping of the 228 lwB4. 230 Some operators may offer different service level agreements (SLA) to 231 users that some users may require more ports then others. In this 232 deployment scenario, the operator can implement differentiated 233 policies in provisioning system specified to a user's lwB4 or a group 234 of lwB4s to allocate a certain range of port-set. The lwAFTR may 235 also run multiple instances with different port-set sizes to build 236 the mapping table. 238 4.3. lwAFTR Discovery 240 A Lightweight 4over6 lwB4 must discover the lwAFTR's IPv6 address 241 before offering any IPv4 services. This IPv6 address can be learned 242 through an out-of-band channel, static configuration, or dynamic 243 configuration. In practice, Lightweight 4over6 lwB4 can use the same 244 DHCPv6 option [RFC6334]to discover the FQDN of the lwAFTR. 246 When Lightweight 4over6 is deployed in the same place with DS-Lite, 247 either different FQDNs can be configured for Lightweight 4over6 and 248 DS-Lite separately or different DHCPv6 options can be used for 249 Lightweight 4over6 [I-D.sun-softwire-lw4over6-dhcpv6] and DS-Lite. 250 More detailed considerations on DS-Lite compatibility will be 251 discussed in Section6. 253 4.4. Impacts on Accouting 255 In Lightweight 4over6, the accounting impact due to the tunneling 256 protocol is the same with DS-Lite (see section 6.2 of [RFC6908]). 257 However, since in Lightweight 4over6, the IPv4 service is only 258 available after port-set allocation, if operators will regard IPv4 259 service as a on-demand value-added service, e.g. IPv6 connectivity 260 is offered by default, while IPv4 connectivity will be offered untill 261 a subscriber requires, etc., IPv4 service accounting should start 262 after port-set allocation has completely. 264 5. lwAFTR Deployment Consideration 266 As Lightweight 4over6 is an extension to DS-Lite, both technologies 267 share similar deployment considerations. For example: Interface 268 consideration, Lawful Intercept Considerations, Blacklisting a shared 269 IPv4 Address, AFTR's Policies, AFTR Impacts on Accounting Process, 270 etc., in [RFC6908] can also be applied here. This document only 271 discusses new considerations specific to Lightweight 4over6. 273 5.1. Logging at the lwAFTR 275 In Lightweight 4over6, operators only log one entry per subscriber. 276 The log should include subscriber's IPv6 address used for the 277 softwire, the public IPv4 address and the port-set. The port set 278 algorithm implemented in Lightweight 4over6 lwAFTR should be 279 synchronized with the one implemented in logging system. For 280 example, if contiguous port set algorithm is adopted in the lwAFTR, 281 the same algorithm should also been applied to the logging system. 283 Since the mapping in lwAFTR does not contain destination-specific 284 information, operator should be aware that they will not be able to 285 have destination-specific log. 287 5.2. MTU and Fragmentation Considerations 289 As Lightweight 4over6 is also a tunneling protocol, the same 290 consideration regarding to the fragmentation and reassembly in DS- 291 Lite [RFC6908] can also be applied. The only difference is that NAT 292 functionality has been removed to lwB4 from lwAFTR in Lightweight 293 4over6. Therefore, on receiving an IPv4 fragmented packet after 294 decapsulation in the lwB4, the lwB4 should further re-assemble the 295 packets before doing NAT since the transport protocol information is 296 only available in the first fragment. 298 5.3. Reliability Considerations of lwAFTR 300 Operators may deploy multiple lwAFTRs for robustness, reliability, 301 and load balancing. In Lightweight 4over6, subscriber to IPv4 and 302 port-set mapping must be pre-provisioned in the lwAFTR before 303 providing IPv4 serives. For redundancy, the backup lwAFTR must 304 either have the subscriber mapping already provisioned or notify the 305 lwB4 to create a new mapping in the backup lwAFTR. The first option 306 can be considered as Hot Standby mode, which requires state 307 syncronization between multiple lwAFTRs. In Hot Standby mode, the 308 bindings are replicated on-the-fly from the Primary lwAFTR to the 309 Backup lwAFTR. When the Primary lwAFTR fails, the Backup lwAFTR will 310 take over all the existing established sessions. In this mode, the 311 internal hosts are not required to re-initiate the bindings with the 312 external hosts. In Lightweight 4over6, since the number of mapping 313 states has been greatly reduced compared to DS-Lite, it is reasonable 314 to adopt Hot Standby mode when there are only two lwAFTRs (one for 315 Primary lwAFTR and one for Backup lwAFTR). However, if the number of 316 lwAFTRs is larger than two, it is not scalable to deploy Hot Standby 317 mode since each two of the lwAFTRs should to syncronize the binding 318 states. 320 The second option is to use Cold Standby mode which does not require 321 a Backup Standby lwAFTR to synchronize binding states. In failover, 322 the lwAFTR has to notify the lwB4 to create a new binding, or fetch 323 the binding by itself. [I-D.lee-softwire-lw4over6-failover] 324 describes these two approaches for simple Cold Standby mode. For 325 most deployment scenarios, we believe that Cold Standby mode should 326 be sufficient enough and is thus recommended. 328 5.4. Placement of AFTR 330 The lwAFTR can be deployed in a "centralized model" or a "distributed 331 model". 333 In the "centralized model", the lwAFTR could be located at the higher 334 place, e.g. at the exit of MAN, etc. Since the lwAFTR has good 335 scalability and can handle numerous concurrent sessions, we recommend 336 to adopt the "centralized model" for Lightweight 4over6 as it is 337 cost-effective and easy to manage. 339 In the "distributed model", lwAFTR is usually integrated with the 340 BRAS/SR. Since newly emerging customers might be distributed in the 341 whole Metro area, we have to deploy lwAFTR on all BRAS/SRs. This 342 will cost a lot in the initial phase of the IPv6 transition period. 344 5.5. Port set algorithm consideration 346 If each lwB4 is given a set of ports, port randomization algorithm 347 can only select port in the given port-set. This may introduce 348 security risk because hackers can make a more predictable guess of 349 what port a subscriber may use. Therefore, non-continuous port set 350 algorithms (e.g. as defined in [I-D.ietf-softwire-map]) can be used 351 to improve security. 353 5.6. Path Consistency Consideration 355 In Lightweight 4over6, if the binding state is not syncronized among 356 multiple lwAFTRs, the lwAFTR in which the subscriber's binding state 357 is stored should be exactly the one to service the subscriber. 358 Otherwise, there will be no match in lwAFTR. This requires the 359 provionsion packets (either using DHCPv4-over-DHCPv6 or PCP Port-set) 360 should arrive at the same lwAFTR as the subsquent IP-in-IP traffic. 361 If multiple lwAFTRs are using the same Tunnel End Point address and 362 there are intermediate routers between lwB4 and lwAFTR, there might 363 be a problem when intermediate routers perform ECMP based on L4 hash 364 for the plain provionsion packets while doing L3 hash for subsequent 365 IP-in-IP traffic. In this case, it is recommended that the 366 privioning packet is sent over IPv6 tunnel so that intermediate 367 routers can only process ECMP using L3 hash. 369 6. lwB4 Deployment Consideration 371 For lwB4 consideration, the DNS Deployment Considerations and B4 372 Remote Management in [RFC6908] can also be applied here. In this 373 section, we only describe the considerations sepcific to Lightweight 374 4over6. 376 6.1. NAT traversal issue 378 In Lightweight 4over6, since the subscriber's source port will be 379 restricted to the port-set allocated from the provisioning system, 380 this will have impact on some NAT traversal mechanisms. For example, 381 in UPnP 1.0, the external port number which can be used by remote 382 peer is selected by UPnP client in end host. If the client randomly 383 selects a port number which is not in that valid port-set, the UPnP 384 process will fail. This is likely to happen because end-host does 385 not know the port-set in lwB4. More detailed experimental results 386 can be found in [I-D.deng-aplusp-experiment-results]. This problem 387 will not exist in UPnP 2.0 because the UPnP client in the end-host 388 will negotiate the external port number with the server. Another way 389 is to implement a mechanism (e.g. [I-D.ietf-pcp-port-set], etc.) in 390 end host to fetch the port-set from lwB4. The UPnP client can then 391 select the port number within the port-set. 393 6.2. Static Port Forwarding Configuration 395 Currently, some external initiated applications rely on manual port 396 configuration to reserve a port in the CPE. The restricted port-set 397 in lwB4 will also have impacts on manual port forwarding 398 configuration. It is recommended that the port-set allocated from 399 the provioning system should be shown explicitly in the lwB4, which 400 can be used as a hint for subscribers to add port forwarding mapping. 402 7. DS-Lite Compatibility Consideration 404 Lightweight 4over6 can be either deployed all alone, or combined with 405 DS-Lite [RFC6333]. Since Lightweight 4over6 does not any have extra 406 requirement on IPv6 addressing, it can use use the same addressing 407 scheme with DS-Lite, together with routing policy, user management 408 policy, etc. Besides, the bottom-up model has quite similar 409 requirement and workflow on the supporting system with DS-Lite. 410 Therefore, it is suitable for operators to deploy incrementally in 411 existing DS-Lite network 413 7.1. Case 1: Integrated Network Element with Lightweight 4over6 and DS- 414 Lite AFTR Scenario 416 In this case, DS-Lite has been deployed in the network. Later in the 417 deployment schedule, the operator decided to implement Lightweight 418 4over6 lwAFTR function in the same network element(depicted in 419 Figure2). Therefore, the same network element needs to support both 420 transition mechanisms. 422 There are two options to distinguish the traffic from two transition 423 mechanisms. 425 The first one is to distinguish using the client's source IPv4 426 address. The IPv4 address from Lightweight 4over6 is public address 427 as NAT has been done in the lwB4, and IPv4 address for DS-lite is 428 private address as NAT will be done on AFTR. When the network 429 element receives an encapsulated packet, it would de-capsulate packet 430 and apply the transition mechanism based on the IPv4 source address 431 in the packet. This requires the network element to examine every 432 packet and may introduce significant extra load to the network 433 element. However, both the B4 element and Lightweight 4over6 lwB4 434 can use the same DHCPv6 option [RFC6334] with the same FQDN of the 435 AFTR and lwAFTR. 437 The second one is to distinguish using the destination's tunnel IPv6 438 address. One network element can run separated instances for 439 Lightweight 4over6 and DS-Lite with different tunnel addresses. Then 440 B4 element and Lightweight 4over6 lwB4 can use the same DHCPv6 option 441 [RFC6334] with different FQDNs pointing to corresponding tunnel 442 addresses. This requires the supporting system should distinguish 443 different types of users when assigning the FQDNs in DHCPv6 process. 444 Another option is to use a new DHCPv6 option 445 [I-D.sun-softwire-lw4over6-dhcpv6] to discover lwAFTR's FQDN. 447 +---------------+--------------| 448 + | | 449 +---------+ +------+---+ +--+--+ | 450 | Host | | LW 4over6| | | | 451 | |--| lwB4| ======-| BNG | === +-------------+ +-----------+ 452 +---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 | 453 |lwAFTR/|---| Internet | 454 +---------+ +------+---+ +--+--+ |DS-Lite AFTR | | | 455 | Host |--| DS-Lite | =======| | ====+-------------+ +-----------+ 456 | | | B4 | | BNG | | 457 +---------+ +----------+ +--|--+ | 458 + | | 459 +---------------+--------------+ 461 Figure 2 DS-Lite Coexistence scenario with Integrated AFTR 463 7.2. Case 2: DS-Lite Coexistent scenario with Separated AFTR 465 This is similar to Case 1. The difference is the lwAFTR and AFTR 466 functions won't be co-located in the same network element (depicted 467 in Figure3). This use case decouples the functions to allow more 468 flexible deployment. For example, an operator may deploy AFTR closer 469 to the edge and lwAFTR closer to the core. Moreover, it does not 470 require the network element to pre-configure with the CPE's IPv6 471 addresses. An operator can deploy more AFTR and lwAFTR at needed. 472 However, this requires the B4 and lwB4 to discover the corresponding 473 network element. In this case, B4 element and Lightweight 4over6 474 lwB4 can still use [RFC6334] with different FQDNs pointing to 475 corresponding tunnel end-point addresses, and the supporting system 476 should distinguish different types of users. 478 +---+---------------+-----------------| 479 + | | 480 +---------+ +------+---+ +------+-----+ | 481 | Host | | LW 4over6| | BNG | | 482 | |--| lwB4| ======-|DS-Lite AFTR| === +------------+ +-----------+ 483 +---------+ +----------+ +------+-----+ |LW 4over6 | | IPv4 | 484 |lwAFTR|---| Internet | 485 +---------+ +------+---+ +------+-----+ | | | | 486 | Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+ 487 | | | B4 | |DS-Lite AFTR| | 488 +---------+ +----------+ +------+-----+ | 489 + | | 490 +-------------------+-----------------+ 492 Figure 3 DS-Lite Coexistence scenario with Seperated AFTR 494 8. Acknowledgement 496 TBD 498 9. References 500 [I-D.bajko-pripaddrassign] 501 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 502 "Port Restricted IP Address Assignment", 503 draft-bajko-pripaddrassign-04 (work in progress), 504 April 2012. 506 [I-D.cui-softwire-b4-translated-ds-lite] 507 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 508 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 509 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 510 (work in progress), February 2013. 512 [I-D.deng-aplusp-experiment-results] 513 Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P 514 in the provider's IPv6-only network", 515 draft-deng-aplusp-experiment-results-00 (work in 516 progress), March 2011. 518 [I-D.ietf-behave-ipfix-nat-logging] 519 Sivakumar, S. and R. Penno, "IPFIX Information Elements 520 for logging NAT Events", 521 draft-ietf-behave-ipfix-nat-logging-00 (work in progress), 522 March 2013. 524 [I-D.ietf-behave-syslog-nat-logging] 525 Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog 526 Format for NAT Logging", 527 draft-ietf-behave-syslog-nat-logging-01 (work in 528 progress), May 2013. 530 [I-D.ietf-dhc-dhcpv4-over-ipv6] 531 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 532 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in 533 progress), March 2013. 535 [I-D.ietf-pcp-base] 536 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 537 Selkirk, "Port Control Protocol (PCP)", 538 draft-ietf-pcp-base-29 (work in progress), November 2012. 540 [I-D.ietf-pcp-port-set] 541 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 542 and S. Perreault, "Port Control Protocol (PCP) Extension 543 for Port Set Allocation", draft-ietf-pcp-port-set-01 (work 544 in progress), May 2013. 546 [I-D.ietf-softwire-4rd] 547 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 548 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 549 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 550 progress), July 2013. 552 [I-D.ietf-softwire-dslite-deployment] 553 Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 554 Boucadair, "Deployment Considerations for Dual-Stack 555 Lite", draft-ietf-softwire-dslite-deployment-08 (work in 556 progress), January 2013. 558 [I-D.ietf-softwire-lw4over6] 559 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 560 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 561 Architecture", draft-ietf-softwire-lw4over6-00 (work in 562 progress), April 2013. 564 [I-D.ietf-softwire-map] 565 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 566 Murakami, T., and T. Taylor, "Mapping of Address and Port 567 with Encapsulation (MAP)", draft-ietf-softwire-map-07 568 (work in progress), May 2013. 570 [I-D.lee-softwire-lw4over6-failover] 571 Lee, Y., Sun, Q., and C. Liu, "Simple Failover Mechanism 572 for Lightweight 4over6", 573 draft-lee-softwire-lw4over6-failover-00 (work in 574 progress), July 2013. 576 [I-D.sun-softwire-lw4over6-dhcpv6] 577 Xie, C., Sun, Q., Lee, Y., Tsou, T., and P. Wu, "Dynamic 578 Host Configuration Protocol for IPv6 (DHCPv6) Option for 579 Lightweight 4over6", draft-sun-softwire-lw4over6-dhcpv6-00 580 (work in progress), July 2013. 582 [I-D.zhou-dime-4over6-provisioning] 583 Zhou, C. and T. Taylor, "Attribute-Value Pairs For 584 Provisioning Customer Equipment Supporting IPv4-Over-IPv6 585 Transitional Solutions", 586 draft-zhou-dime-4over6-provisioning-00 (work in progress), 587 March 2013. 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 593 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 594 October 2010. 596 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 597 Stack Lite Broadband Deployments Following IPv4 598 Exhaustion", RFC 6333, August 2011. 600 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 601 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 602 RFC 6334, August 2011. 604 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 605 T. Tsou, "Huawei Port Range Configuration Options for PPP 606 IP Control Protocol (IPCP)", RFC 6431, November 2011. 608 [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 609 Boucadair, "Deployment Considerations for Dual-Stack 610 Lite", RFC 6908, March 2013. 612 1. Appendix:Experimental Result 614 We have deployed Lightweight 4over6 in our operational network of 615 HuNan province, China. It is designed for broadband access network, 616 and different versions of lwB4 have been implemented including a 617 linksys box, a software client for windows XP, vista and Windows 7. 618 It can be integrated with existing dial-up mechanisms such as PPPoE, 619 etc. The major objectives listed below aimed to verify the 620 functionality and performance of Lightweight 4over6: 622 o Verify how to deploy Lightweight 4over6 in a practical network. 624 o Verify the impact of applications with Lightweight 4over6. 626 o Verify the performance of Lightweight 4over6. 628 1.1. Experimental environment 630 The network topology for this experiment is depicted in Figure 2. 632 +--------+ 633 +-----+ +---------+ | Syslog | 634 |Host1+--+lwB4|--+ | Server | -------- 635 +-----+ +---------+ | +---+----+ /// \\\ 636 | /------\ | // \\ 637 | // \\ +---+----+ | | 638 +-----+ +---------+ +-+--+ | IPv6 | | | | IPv4 Internet | 639 |Host2+--|lwB4|--+BRAS+--| Network |---| Concen-+-+ | 640 +-----+ +---------+ +-+--+ \\ // | trator | \\ // 641 | \---+--/ +--------+ \\\ /// 642 | | --------- 643 +-----+ +---------+ | | 644 |Host3+--+lwB4+---+ | 645 +-----+ +---------+ | -------- 646 | // \\ 647 | / \ 648 +---------------------+IPv6 Internet + 649 | | 650 \ / 651 \\ // 652 ------- 654 Figure 2 Lightweight 4over6 experiment topology 656 In this deployment model, lwAFTR is co-located with a extended PCP 657 server to assign restricted IPv4 address and port set for lwB4. It 658 also triggers subscriber-based logging event to a centrilized syslog 659 server. IPv6 address pools for subscribers have been distributed to 660 BRASs for configuration, while the public available IPv4 address 661 pools are configured by the centralized lwAFTR with a default address 662 sharing ratio. It is rather flexible for IPv6 addressing and 663 routing, and there is little impact on existing IPv6 architecture. 665 In our experiment, lwB4 will firstly get its IPv6 address and 666 delegated prefix through PPPoE, and then initiate a PCP-extended 667 request to get public IPv4 address and its valid port set. The 668 lwAFTR will thus create a subscriber-based state accordingly, and 669 notify syslog server with {IPv6 address, IPv4 address, port set, 670 timestamp}. 672 1.2. Experimental results 674 In our trial, we mainly focused on application test and performance 675 test. The applications have widely include web, email, Instant 676 Message, ftp, telnet, SSH, video, Video Camera, P2P, online game, 677 voip and so on. For performance test, we have measured the 678 parameters of concurrent session numbers and throughput performance. 680 The experimental results are listed as follows: 682 +--------------------+----------------------+-----------------------+ 683 | Application Type | Test Result |Port Number Occupation | 684 +--------------------+----------------------+-----------------------+ 685 | Web | ok | normal websites: 10~20| 686 | | IE, Firefox, Chrome | Ajex Flash webs: 30~40| 687 +--------------------+----------------------+-----------------------+ 688 | Video | ok, web based or | 30~40 | 689 | | client based | | 690 +--------------------+----------------------+-----------------------+ 691 | Instant Message | ok | | 692 | | QQ, MSN, gtalk, skype| 8~20 | 693 +--------------------+----------------------+-----------------------+ 694 | P2P | ok | lower speed: 20~600 | 695 | |utorrent,emule,xunlei | (per seed) | 696 | | | higher speed: 150~300 | 697 +--------------------+----------------------+-----------------------+ 698 | FTP | need ALG for active | 2 | 699 | | mode, flashxp | | 700 +--------------------+----------------------+-----------------------+ 701 | SSH, TELNET | ok |1 for SSH, 3 for telnet| 702 +--------------------+----------------------+-----------------------+ 703 | online game | ok for QQ, flash game| 20~40 | 704 +--------------------+----------------------+-----------------------+ 706 Figure 3 Lightweight 4over6 experimental result 707 The performance test for lwAFTR is taken on a normal PC. Due to 708 limitations of the PC hardware, the overall throughput is limited to 709 around 800 Mbps. However, it can still support more than one hundred 710 million concurrent sessions. 712 1.3. Conclusions 714 From the experiment, we can have the following conclusions: 716 o Lightweight 4over6 has good scalability. As it is a lightweight 717 solution which only maintains per-subscription state information, 718 it can easily support a large amount of concurrent subscribers. 720 o Lightweight 4over6 can be deployed rapidly. There is no 721 modification to existing addressing and routing system in our 722 operational network. And it is simple to achieve traffic logging. 724 o Lightweight 4over6 can support a majority of current IPv4 725 applications. 727 Authors' Addresses 729 Qiong Sun 730 China Telecom 731 Room 708, No.118, Xizhimennei Street 732 Beijing 100035 733 P.R.China 735 Phone: +86-10-58552936> 736 Email: sunqiong@ctbri.com.cn 738 Chongfeng Xie 739 China Telecom 740 Room 708, No.118, Xizhimennei Street 741 Beijing 100035 742 P.R.China 744 Phone: +86-10-58552116> 745 Email: xiechf@ctbri.com.cn 747 Yiu L. Lee 748 Comcast 749 One Comcast Center 750 Philadelphia, PA 19103 751 USA 753 Email: yiu_lee@cable.comcast.com 755 Maoke Chen 756 FreeBit Co., Ltd. 757 13F E-space Tower, Maruyama-cho 3-6 758 Shibuya-ku, Tokyo 150-0044 759 Japan 761 Email: fibrib@gmail.com