idnits 2.17.1 draft-ieft-softwire-dslite-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2011) is 4607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-server-logging-recommendations' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipv6-cpe-router' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-behave-stateful-nat-standby' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 579, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-13 == Outdated reference: A later version (-07) exists of draft-ietf-softwire-dslite-radius-ext-06 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Y. Lee 3 Internet-Draft Comcast 4 Intended status: Informational R. Maglione 5 Expires: March 12, 2012 Telecom Italia 6 C. Williams 7 MCSR Labs 8 C. Jacquenet 9 M. Boucadair 10 France Telecom 11 September 9, 2011 13 Deployment Considerations for Dual-Stack Lite 14 draft-ieft-softwire-dslite-deployment-00 16 Abstract 18 This document discusses the deployment issues and describes 19 requirements for the deployment and operation of Dual-Stack Lite. 20 This document describes the various deployment considerations and 21 applicability of the Dual-Stack Lite 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 March 12, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. AFTR Deployment Considerations . . . . . . . . . . . . . . . . 3 59 2.1. Interface Consideration . . . . . . . . . . . . . . . . . 3 60 2.2. MTU Considerations . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 62 2.4. Lawful Intercept Considerations . . . . . . . . . . . . . 4 63 2.5. Logging at the AFTR . . . . . . . . . . . . . . . . . . . 4 64 2.6. Blacklisting a shared IPv4 Address . . . . . . . . . . . . 5 65 2.7. AFTR's Policies . . . . . . . . . . . . . . . . . . . . . 5 66 2.8. AFTR Impacts on Accounting Process in Broadband Access . . 5 67 2.9. Reliability Considerations of AFTR . . . . . . . . . . . . 6 68 2.10. Strategic Placement of AFTR . . . . . . . . . . . . . . . 6 69 2.11. AFTR Considerations for Geographically Aware Services . . 7 70 2.12. Impacts on QoS . . . . . . . . . . . . . . . . . . . . . . 8 71 2.13. Port Forwarding Considerations . . . . . . . . . . . . . . 8 72 2.14. DS-Lite Tunnel Security . . . . . . . . . . . . . . . . . 8 73 2.15. IPv6-only Network considerations . . . . . . . . . . . . . 9 74 3. B4 Deployment Considerations . . . . . . . . . . . . . . . . . 9 75 3.1. DNS deployment Considerations . . . . . . . . . . . . . . 10 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Overview 87 Dual-stack Lite (DS-Lite) [I-D.ietf-softwire-dual-stack-lite] is a 88 transition technique that enable operators to multiplex public IPv4 89 addresses while provisioning only IPv6 to users. DS-Lite is designed 90 to address the IPv4 depletion issue and allow the operators to 91 upgrade their network incrementally to IPv6. DS-Lite combines IPv4- 92 in-IPv6 tunnel and NAT44 to share a public IPv4 address more than one 93 user. This document discusses various deployment considerations for 94 DS-Lite by operators. 96 2. AFTR Deployment Considerations 98 2.1. Interface Consideration 100 Address Family Transition Router (AFTR) is the function deployed 101 inside the operator's network. AFTR can be a standalone device or 102 embedded into a router. AFTR is the IPv4-in-IPv6 tunnel termination 103 point and the NAT44 device. It is deployed at the IPv4-IPv6 network 104 border where the tunnel interface is IPv6 and the NAT interface is 105 IPv4. Although an operator can configure a dual-stack interface for 106 both functions, we recommended to configure two individual interfaces 107 (i.e. one dedicated for IPv4 and one dedicated for IPv6) to segregate 108 the functions. 110 2.2. MTU Considerations 112 DS-Lite is part tunneling protocol. Tunneling introduces some 113 additional complexity and has a risk of MTU. With tunneling comes 114 additional header overhead that implies that the tunnel's MTU is 115 smaller than the raw interface MTU. The issue that the end user may 116 experience is that they cannot download Internet pages or transfer 117 files using File Transfer Protocol (FTP). 119 To mitigate the tunnel overhead, the access network could increase 120 the MTU size to account the necessary tunnel overhead which is the 121 size of an IPv6 header. If the access network MTU size is fixed and 122 cannot be changed, the B4 element and the AFTR must support 123 fragmentation. 125 2.3. Fragmentation 127 The IPv4-in-IPv6 tunnel is between B4 and AFTR. When a host behind 128 the B4 element communicates to a server, both the host and the server 129 are not aware of the tunnel. They may continue to use the maximum 130 MTU size for communication. In fact, the IPv4 packet isn't over- 131 sized, it is the v6 encapsulation that may cause the oversize. So 132 the tunnel points are responsible to handle the fragmentation. In 133 general, the Tunnel-Entry Point and Tunnel-Exist Point should 134 fragment and reassemble the oversized datagram. If the DF is set, 135 the B4 element should send an ICMP "Destination Unreachable" with 136 "Fragmentation Needed and Don't Fragment was Set" and drop the 137 packet. If the DF is not set, the B4 element should fragment the 138 IPv6 packet after the encapsulation. This mechanism is transport 139 protocol agnostic and works for both UDP and TCP. 141 [editor note: Should we drop the IPv4 packet when DF is set?] 143 2.4. Lawful Intercept Considerations 145 Because of its IPv4-in-IPv6 tunneling scheme, interception of IPv4 146 sessions in DS-Lite architecture must be performed on the AFTR. 147 Subjects can be uniquely identified by the IPv6 address assigned to 148 the B4 element. Operator must associate the B4's IPv6 address and 149 the public IPv4 address and port used by the subject. 151 Monitoring of a single subject may mean statically mapping the 152 subject to a certain range of ports on a single IPv4 address, to 153 remove the need to follow dynamic port mappings. A single IPv4 154 address, or some range of ports for each address, might be set aside 155 for monitoring purposes to simplify such procedures. This requires 156 to create a static mapping of a B4 element's IPv6 address to an IPv4 157 address that used for lawful intercept. 159 2.5. Logging at the AFTR 161 The timestamped logging is essential for tracing back specific users 162 when a problem is identified from the outside of the AFTR. Such a 163 problem is usually a misbehaving user in the case of a spammer or a 164 DoS source, or someone violating a usage policy. Without time- 165 specific logs of the address and port mappings, a misbehaving user 166 stays well hidden behind the AFTR. 168 In DS-Lite framework, each B4 element is given a unique IPv6 address. 169 The AFTR uses this IPv6 address to identify the B4 element. Thus, 170 the AFTR must log the B4's IPv6 address and the IPv4 information. 171 There are two types of logging: (1) Source-Specific Log and (2) 172 Destination-Specific Log. For Source-Specific Log, the AFTR must 173 timestamped log the B4's IPv6 address, transport protocol, source 174 IPv4 address after NAT-ed, and source port. If a range of ports is 175 dynamically assigned to a B4 element, the AFTR may create one log per 176 range of ports to aggregate number of log entries. For Destination- 177 Specific Log, the AFTR must timestamped log the B4's IPv6 address, 178 transport protocol, source IPv4 address after NAT-ed, source port, 179 destination address and destination port. The AFTR must log every 180 session from the B4 elements. No log aggregation can be performed. 181 When using Destination-Specific Log, the operator must be careful of 182 the large number of log entries created by the AFTR. 184 2.6. Blacklisting a shared IPv4 Address 186 AFTR is a NAT device. It shares a single IPv4 address with multiple 187 users. [I-D.ietf-intarea-shared-addressing-issues] discusses many 188 considerations when sharing address. When a pubic IPv4 address is 189 blacklisted, this may affect multiple users and there is no effective 190 way for the B4 element to notify the AFTR an IP address is 191 blacklisted. It is recommended the server must no longer rely solely 192 on IP address to identify an abused user. The server should combine 193 the information stored in the transport layer (e.g. source port) and 194 application layer (e.g. HTTP) to identify an abused user. 195 [I-D.boucadair-intarea-nat-reveal-analysis] analyzes different 196 approaches to identify a user in a shared address environment. 198 2.7. AFTR's Policies 200 There are two types of AFTR polices: (1) Outgoing Policies and (2) 201 Incoming Policies. The outgoing policies must be implemented on the 202 AFTR's internal interface connected to the B4 elements. The policies 203 may include ACL and QoS settings. For example: the AFTR may only 204 accept B4's connections originated from the IPv6 prefixes provisioned 205 in the AFTR. The AFTR may also give priority to the packets marked 206 by certain DSCP values. The AFTR may also limit the rate of port 207 creation from a single B4's IPv6 address. Outgoing policies could be 208 applied to individual B4 element or a set of B4 elements. 210 The incoming policies must be implemented on the AFTR's external 211 interface connected to the IPv4 network. Similar to the outgoing 212 policies, the policies may include ACL and QoS settings. Incoming 213 policies are usually more general and globally applied to all users 214 rather than individual user. 216 2.8. AFTR Impacts on Accounting Process in Broadband Access 218 DS-Lite introduces challenges to IPv4 accounting process. In a 219 typical DSL/Broadband access scenario where the Residential Gateway 220 (RG) is acting as a B4 element, the BNAS is the IPv6 edge router 221 which connects to the AFTR. The BNAS is normally responsible for 222 IPv6 accounting and all the subscriber manager functions such as 223 authentication, authorization and accounting. However, given the 224 fact that IPv4 traffic is encapsulated into an IPv6 packet at the B4 225 level and only decapsulated at the ATFR level, the BNAS can't do the 226 IPv4 accounting without examining the inner packet. AFTR is the next 227 logical place to perform IPv4 accounting, but it will potentially 228 introduce some additional complexity because the AFTR does not have 229 detailed customer identity information. 231 The accounting process at the AFTR level is only necessary if the 232 Service Provider requires separate per user accounting records for 233 IPv4 and IPv6 traffic. If the per user IPv6 accounting records, 234 collected by the BNAS, are sufficient, the additional complexity to 235 be able to implement IPv4 accounting at the ATFR level is not 236 required. It is important to consider that, since the IPv4 traffic 237 is encapsulated in IPv6 packets, the data collected by the BNAS for 238 IPv6 traffic already contain the total amount of traffic (i.e. IPv6 239 plus IPv4). 241 Even if detailed accounting records collection for IPv4 traffic may 242 not be required, in some scenarios it would be useful for a Service 243 Provider, to have inside the RADIUS Accounting packet, generated by 244 the BNAS for the IPv6 traffic, a piece of information that can be 245 used to identify the AFTR that is handling the IPv4 traffic for that 246 user. This can be achieved by adding into the IPv6 accounting 247 records the RADIUS attribute information specified in 248 [I-D.ietf-softwire-dslite-radius-ext] 250 2.9. Reliability Considerations of AFTR 252 The service provider can use techniques to achieve high availability 253 such as various types of clusters to ensure availability of the IPv4 254 service. High availability techniques include the cold standby mode. 255 In this mode the AFTR states are not replicated from the Primary AFTR 256 to the Backup AFTR. When the Primary AFTR fails, all the existing 257 established sessions will be flushed out. The internal hosts are 258 required to re-establish sessions to the external hosts. Another 259 high availability option is the hot standby mode. In this mode the 260 AFTR keeps established sessions while failover happens. AFTR states 261 are replicated from the Primary AFTR to the Backup AFTR. When the 262 Primary AFTR fails, the Backup AFTR will take over all the existing 263 established sessions. In this mode the internal hosts are not 264 required to re-establish sessions to the external hosts. The final 265 option is to deploy a mode in between these two whereby only selected 266 sessions such as critical protocols are replicated. Criteria for 267 sessions to be replicated on the backup would be explicitly 268 configured on the AFTR devices of a redundancy group. 270 2.10. Strategic Placement of AFTR 272 The public IPv4 addresses are pulled away from the customer edge to 273 the outside of the centralized AFTR where many customer networks can 274 share a single public IPv4 address. The AFTR architecture design is 275 mostly figuring out the strategic placement of each AFTR to best use 276 the capacity of each public IPv4 address without oversubscribing the 277 address or overtaxing the AFTR itself. 279 AFTR is a tunnel concentrator, B4 traffic must pass through the AFTR 280 to reach the IPv4 Internet. Managing tunnels and NAT could be 281 resource intensive, so the placement of the AFTR would affect the 282 traffic flows in the access network and have operation implications. 283 In general, there are two placements to deploy AFTR. Model One is to 284 deploy the AFTR in the edge of network to cover a small region. 285 Model Two is to deploy the AFTR in the core of network to cover a 286 large region. 288 When the operator consider where to deploy the AFTR, they must make 289 trade-offs. AFTR in Model One serves few B4 elements, thus, it 290 requires less powerful AFTR. Moreover, the traffic flows are more 291 evenly distributed to the AFTRs. However, it requires to deploy more 292 AFTRs to cover the entire network. Often the operation cost 293 increases proportionally to the number of network equipment. AFTR in 294 Model Two covers larger area, thus, it serves more B4 elements. The 295 operator could deploy only few AFTRs in the strategic locations to 296 support the entire subscriber base. However, this model requires 297 more powerful AFTR to sustain the load at peak hours. Since the AFTR 298 would support B4 elements from different regions, the AFTR would be 299 deployed deeper in the network and steer more traffic flows to the 300 network where the AFTR is located. 302 DS-Lite framework can be incrementally deployed. An operator may 303 consider to start with Model Two. When the demand increases, they 304 could push the AFTR closer to the edge which would effectively become 305 Model One. 307 2.11. AFTR Considerations for Geographically Aware Services 309 By centralizing public IPv4 addresses, each address no longer 310 represents a single machine, a single household, or a single small 311 office. The address now represents hundreds of machines, homes, and 312 offices related only in that they are behind the same AFTR. 313 Identification by IP address becomes more difficult and thus 314 applications that assume such geographic information may not work as 315 intended. 317 Various applications and services will place their servers in such a 318 way to locate them near sets of user so that this will lessen the 319 latency on the client end. In addition, having sufficient 320 geographical coverage can indirectly improve end-to-end latency. An 321 example is that nameservers typically return results optimized for 322 the DNS resolver's location. Deployment of AFTR could be done in 323 such a way as not to negatively impact the geographical nature of 324 these services. This can be done by making sure that AFTR 325 deployments are geographically distributed so that existing 326 assumptions of the clients source IP address by geographically aware 327 servers can be maintained. Another possibility the application could 328 rely on location information such as GPS co-ordination to identify 329 the user's location. This technique is commonly used in mobile 330 deployment where the mobile devices are probably behind a NAT device. 332 2.12. Impacts on QoS 334 As with tunneling in general there are challenges with deep packet 335 inspection with DS-Lite for purposes of QoS. Service Providers 336 commonly uses DSCP to classify and prioritize different types of 337 traffic. DS-Lite tunnel can be seen as particular case of uniform 338 conceptual tunnel model described in section 3.1 of [RFC2983]. The 339 uniform model views an IP tunnel as just a necessary mechanism to get 340 traffic to its destination, but the tunnel has no significant impact 341 on traffic conditioning. In this model, any packet has exactly one 342 DS Field that is used for traffic conditioning at any point and it is 343 the field in the outermost IP header. In DS-Lite model this is the 344 Traffic Class field in IPv6 header. According to [RFC2983] 345 implementations of this model copy the DS value to the outer IP 346 header at encapsulation and copy the outer header's DSCP value to the 347 inner IP header at decapsulation. Applying the described model to 348 DS-Lite scenario, it is recommended that the AFTR propagates the DSCP 349 value in the IPv4 header to the IPv6 header after the encapsulation 350 for the downstream traffic and, in the same way, the B4 propagates 351 the DSCP value in the IPv4 header to the IPv6 header after the 352 encapsulation for the upstream traffic. 354 2.13. Port Forwarding Considerations 356 Some applications require accepting incoming UDP or TCP traffic. 357 When the remote host is on IPv4, the incoming traffic will be 358 directed towards an IPv4 address. Some applications use (UPnP-IGD) 359 (e.g., XBox) or ICE [I-D.ietf-mmusic-ice] (e.g., SIP, Yahoo!, Google, 360 Microsoft chat networks), other applications have all but completely 361 abandoned incoming connections (e.g., most FTP transfers use passive 362 mode). But some applications rely on ALGs, UPnP IGD, or manual port 363 configuration. Port Control Protocol (PCP) [I-D.ietf-pcp-base] is 364 designed to address this issues. 366 2.14. DS-Lite Tunnel Security 368 Section 11 of [I-D.ietf-softwire-dual-stack-lite] describes security 369 issues associated to DS-Lite mechanism. One of the recommendations 370 contained in this section, in order to limit service offered by AFTR 371 only to registered customers, is to implement IPv6 ingress filter on 372 the AFTR's tunnel interface to accept only the IPv6 address range 373 defined in the filter. This approach requires to know in advance the 374 IPv6 prefix delegated to the customers in order to be able to 375 configure the filter. 377 An alternative way to achieve the same goal and to provide some form 378 of access control to the DS-Lite tunnel, is to use DHCPv6 Leasequery 379 defined in [RFC5007]. When the AFTR receives a packet from an 380 unknown (new) prefix it issues a DHCPv6 Leasequery based on IPv6 381 address to the DHCPv6 server in order to verify if that prefix was 382 previously delegated by the DHCPv6 server to that specific client. 383 The DHCPv6 Server will reply with the delegated prefix and the 384 associated lease. If the two prefix are the same the ATFR accepts 385 the packet otherwise it drops it and it denies the service. 387 2.15. IPv6-only Network considerations 389 In environments where the service provider wants to deploy AFTR in 390 the IPv6 core network, the AFTR nodes may not have direct IPv4 391 connectivity. In this scenario the service provider extends the 392 IPv6-only boundary to the border of the network and only the border 393 routers have IPv4 connectivity. For both scalability and performance 394 purposes AFTR capabilities are located in the IPv6-only core closer 395 to B4 elements. The service provider assigns only IPv6 prefixes to 396 the B4 capable devices but also continues to provide IPv4 services to 397 these customers. In this scenario the AFTR has only IPv6- 398 connectivity and must be able to send and receive IPv4 packets. 399 Enhancements to the DS-LITE AFTR are required to achive this. 400 [I-D.boucadair-softwire-dslite-v6only] describes such issues and 401 enhancements to DS-Lite in IPv6-only deployments. 403 3. B4 Deployment Considerations 405 In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs 406 the IPv6 address of the AFTR element. This IPv6 address can be 407 configured using a variety of methods, ranging from an out-of-band 408 mechanism, manual configuration or a variety of DHCPv6 options. In 409 order to guarantee interoperability, a B4 element should implement 410 the DHCPv6 option defined in 411 [I-D.ietf-softwire-ds-lite-tunnel-option]. The DHCP server must be 412 reachable via normal DHCP request channels from the B4, and it must 413 be configured with the AFTR address. In Broadband Access scenario 414 where AAA/RADUIS is used for provisioning user profiles in the BNAS, 415 [I-D.ietf-softwire-dslite-radius-ext] may be used. BNAS will learn 416 the AFTR address from the RADIUS attribute and act as the DHCPv6 417 server for the B4s. 419 3.1. DNS deployment Considerations 421 [I-D.ietf-softwire-dual-stack-lite] recommends configuring the B4 422 with a DNS proxy resolver, which will forward queries to an external 423 recursive resolver over IPv6. Alternately, the B4 proxy resolver can 424 be statically configured with the IPv4 address of an external 425 recursive resolver. In this case, DNS traffic to the external 426 resolver will be tunneled through IPv6 to the AFTR. Note that the B4 427 must also be statically configured with an IPv4 address in order to 428 source packets; the draft recommends an address in the 192.0.0.0/29 429 range. Even more simply, you could eliminate the DNS proxy, and 430 configure the DHCP server on the B4 to give its clients the IPv4 431 address of an external recursive resolver. Because of the extra 432 traffic through the AFTR, and because of the need to statically 433 configure the B4, these alternate solutions are likely to be 434 unsatisfactory in a production environment. However, they may be 435 desirable in a testing or demonstration environment. 437 4. Security Considerations 439 This document does not present any new security issues. 440 [I-D.ietf-softwire-dual-stack-lite] discusses DS-Lite related 441 security issues. General NAT security issues are not repeated here. 443 Some of the security issues with carrier-grade NAT result directly 444 from the sharing of the routable IPv4 address. Addresses and 445 timestamps are often used to identify a particular user, but with 446 shared addresses, more information (i.e., protocol and port numbers) 447 is needed. This impacts software used for logging and tracing spam, 448 denial of service attacks, and other abuses. Devices on the 449 customers side may try to carry out general attacks against systems 450 on the global Internet or against other customers by using 451 inappropriate IPv4 source addresses inside tunneled traffic. The 452 AFTR needs to protect against such abuse. One customer may try to 453 carry out a denial of service attack against other customers by 454 monopolizing the available port numbers. The AFTR needs to ensure 455 equitable access. At a more sophisticated level, a customer may try 456 to attack specific ports used by other customers. This may be more 457 difficult to detect and to mitigate without a complete system for 458 authentication by port umber, which would represent a huge security 459 requirement. 461 5. Conclusion 463 DS-Lite provides new functionality to transition IPv4 traffic to IPv6 464 addresses. As the supply of unique IPv4 addresses diminishes, 465 service providers can now allocate new subscriber homes IPv6 466 addresses and IPv6-capable equipment. DS-Lite provides a means for 467 the private IPv4 addresses behind the IPv6 equipment to reach the 468 IPv4 network. 470 This document discusses the issues that arise when deploying DS-Lite 471 in various deployment modes. Hence, this document can be a useful 472 reference for service providers and network designers. Deployment 473 considerations of the B4, AFTR and DNS have been discussed and 474 recommendations for their usage have been documented. 476 6. Acknowledgement 478 TBD 480 7. IANA Considerations 482 This memo includes no request to IANA. 484 8. References 486 8.1. Normative References 488 [I-D.ietf-pcp-base] 489 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 490 Selkirk, "Port Control Protocol (PCP)", 491 draft-ietf-pcp-base-13 (work in progress), July 2011. 493 [I-D.ietf-softwire-ds-lite-tunnel-option] 494 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 495 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 496 draft-ietf-softwire-ds-lite-tunnel-option-10 (work in 497 progress), March 2011. 499 [I-D.ietf-softwire-dslite-radius-ext] 500 Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 501 Stack Lite", draft-ietf-softwire-dslite-radius-ext-06 502 (work in progress), August 2011. 504 [I-D.ietf-softwire-dual-stack-lite] 505 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 506 Stack Lite Broadband Deployments Following IPv4 507 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 508 in progress), May 2011. 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 514 Problem Statement", RFC 4925, July 2007. 516 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 517 "DHCPv6 Leasequery", RFC 5007, September 2007. 519 8.2. Informative References 521 [I-D.boucadair-intarea-nat-reveal-analysis] 522 Boucadair, M., Touch, J., Levis, P., and R. Penno, 523 "Analysis of Solution Candidates to Reveal a Host 524 Identifier in Shared Address Deployments", 525 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 526 progress), September 2011. 528 [I-D.boucadair-softwire-dslite-v6only] 529 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 530 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 531 Stack Lite in IPv6 Network", 532 draft-boucadair-softwire-dslite-v6only-01 (work in 533 progress), April 2011. 535 [I-D.ietf-intarea-server-logging-recommendations] 536 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 537 "Logging recommendations for Internet facing servers", 538 draft-ietf-intarea-server-logging-recommendations-04 (work 539 in progress), April 2011. 541 [I-D.ietf-intarea-shared-addressing-issues] 542 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 543 Roberts, "Issues with IP Address Sharing", 544 draft-ietf-intarea-shared-addressing-issues-05 (work in 545 progress), March 2011. 547 [I-D.ietf-mmusic-ice] 548 Rosenberg, J., "Interactive Connectivity Establishment 549 (ICE): A Protocol for Network Address Translator (NAT) 550 Traversal for Offer/Answer Protocols", 551 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 553 [I-D.ietf-v6ops-ipv6-cpe-router] 554 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 555 Troan, "Basic Requirements for IPv6 Customer Edge 556 Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in 557 progress), December 2010. 559 [I-D.xu-behave-stateful-nat-standby] 560 Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy 561 Requirements and Framework for Stateful Network Address 562 Translators (NAT)", 563 draft-xu-behave-stateful-nat-standby-06 (work in 564 progress), October 2010. 566 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 567 E. Lear, "Address Allocation for Private Internets", 568 BCP 5, RFC 1918, February 1996. 570 [RFC2983] Black, D., "Differentiated Services and Tunnels", 571 RFC 2983, October 2000. 573 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 574 via IPv4 Clouds", RFC 3056, February 2001. 576 [RFC3484] Draves, R., "Default Address Selection for Internet 577 Protocol version 6 (IPv6)", RFC 3484, February 2003. 579 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 580 Infrastructures (6rd)", RFC 5569, January 2010. 582 Authors' Addresses 584 Yiu L. Lee 585 Comcast 586 One Comcast Center 587 Philadelphia, PA 19103 588 U.S.A. 590 Email: yiu_lee@cable.comcast.com 591 URI: http://www.comcast.com 593 Roberta Maglione 594 Telecom Italia 595 Via Reiss Romoli 274 596 Torino 10148 597 Italy 599 Email: roberta.maglione@telecomitalia.it 600 URI: 602 Carl Williams 603 MCSR Labs 604 Philadelphia 605 U.S.A. 607 Email: carlw@mcsr-labs.org 609 Christian Jacquenet 610 France Telecom 611 Rennes 612 France 614 Email: christian.jacquenet@orange-ftgroup.com 616 Mohamed Boucadair 617 France Telecom 618 Rennes 619 France 621 Email: mohamed.boucadair@orange-ftgroup.com