idnits 2.17.1 draft-ietf-softwire-dslite-deployment-01.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 (October 31, 2011) is 4555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-behave-stateful-nat-standby' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC6302' is defined on line 565, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-16 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 4 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: May 3, 2012 Telecom Italia 6 C. Williams 7 MCSR Labs 8 C. Jacquenet 9 M. Boucadair 10 France Telecom 11 October 31, 2011 13 Deployment Considerations for Dual-Stack Lite 14 draft-ietf-softwire-dslite-deployment-01 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 May 3, 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) [RFC6333] is a transition technique that 88 enable operators to multiplex public IPv4 addresses while 89 provisioning only IPv6 to users. DS-Lite is designed to address the 90 IPv4 depletion issue and allow the operators to upgrade their network 91 incrementally to IPv6. DS-Lite combines IPv4-in-IPv6 tunnel and 92 NAT44 to share a public IPv4 address more than one user. This 93 document discusses various deployment considerations for DS-Lite by 94 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. [RFC6269] discusses many considerations when sharing address. 188 When a pubic IPv4 address is blacklisted, this may affect multiple 189 users and there is no effective way for the B4 element to notify the 190 AFTR an IP address is blacklisted. It is recommended the server must 191 no longer rely solely on IP address to identify an abused user. The 192 server should combine the information stored in the transport layer 193 (e.g. source port) and application layer (e.g. HTTP) to identify an 194 abused user. [I-D.boucadair-intarea-nat-reveal-analysis] analyzes 195 different approaches to identify a user in a shared address 196 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 [RFC5245] (e.g., SIP, Yahoo!, Google, Microsoft 360 chat networks), other applications have all but completely abandoned 361 incoming connections (e.g., most FTP transfers use passive mode). 362 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 [RFC6333] describes security issues associated to DS- 369 Lite mechanism. One of the recommendations contained in this 370 section, in order to limit service offered by AFTR only to registered 371 customers, is to implement IPv6 ingress filter on the AFTR's tunnel 372 interface to accept only the IPv6 address range defined in the 373 filter. This approach requires to know in advance the IPv6 prefix 374 delegated to the customers in order to be able to configure the 375 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 [RFC6334]. The DHCP server must be 411 reachable via normal DHCP request channels from the B4, and it must 412 be configured with the AFTR address. In Broadband Access scenario 413 where AAA/RADUIS is used for provisioning user profiles in the BNAS, 414 [I-D.ietf-softwire-dslite-radius-ext] may be used. BNAS will learn 415 the AFTR address from the RADIUS attribute and act as the DHCPv6 416 server for the B4s. 418 3.1. DNS deployment Considerations 420 [RFC6333] recommends queries to an external recursive resolver over 421 IPv6. Alternately, the B4 proxy resolver can be statically 422 configured with the IPv4 address of an external recursive resolver. 423 In this case, DNS traffic to the external resolver will be tunneled 424 through IPv6 to the AFTR. Note that the B4 must also be statically 425 configured with an IPv4 address in order to source packets; the draft 426 recommends an address in the 192.0.0.0/29 range. Even more simply, 427 you could eliminate the DNS proxy, and configure the DHCP server on 428 the B4 to give its clients the IPv4 address of an external recursive 429 resolver. Because of the extra traffic through the AFTR, and because 430 of the need to statically configure the B4, these alternate solutions 431 are likely to be unsatisfactory in a production environment. 432 However, they may be desirable in a testing or demonstration 433 environment. 435 4. Security Considerations 437 This document does not present any new security issues. [RFC6333] 438 discusses DS-Lite related security issues. General NAT security 439 issues are not repeated here. 441 Some of the security issues with carrier-grade NAT result directly 442 from the sharing of the routable IPv4 address. Addresses and 443 timestamps are often used to identify a particular user, but with 444 shared addresses, more information (i.e., protocol and port numbers) 445 is needed. This impacts software used for logging and tracing spam, 446 denial of service attacks, and other abuses. Devices on the 447 customers side may try to carry out general attacks against systems 448 on the global Internet or against other customers by using 449 inappropriate IPv4 source addresses inside tunneled traffic. The 450 AFTR needs to protect against such abuse. One customer may try to 451 carry out a denial of service attack against other customers by 452 monopolizing the available port numbers. The AFTR needs to ensure 453 equitable access. At a more sophisticated level, a customer may try 454 to attack specific ports used by other customers. This may be more 455 difficult to detect and to mitigate without a complete system for 456 authentication by port umber, which would represent a huge security 457 requirement. 459 5. Conclusion 461 DS-Lite provides new functionality to transition IPv4 traffic to IPv6 462 addresses. As the supply of unique IPv4 addresses diminishes, 463 service providers can now allocate new subscriber homes IPv6 464 addresses and IPv6-capable equipment. DS-Lite provides a means for 465 the private IPv4 addresses behind the IPv6 equipment to reach the 466 IPv4 network. 468 This document discusses the issues that arise when deploying DS-Lite 469 in various deployment modes. Hence, this document can be a useful 470 reference for service providers and network designers. Deployment 471 considerations of the B4, AFTR and DNS have been discussed and 472 recommendations for their usage have been documented. 474 6. Acknowledgement 476 TBD 478 7. IANA Considerations 480 This memo includes no request to IANA. 482 8. References 484 8.1. Normative References 486 [I-D.ietf-pcp-base] 487 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 488 Selkirk, "Port Control Protocol (PCP)", 489 draft-ietf-pcp-base-16 (work in progress), October 2011. 491 [I-D.ietf-softwire-dslite-radius-ext] 492 Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 493 Stack Lite", draft-ietf-softwire-dslite-radius-ext-07 494 (work in progress), October 2011. 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 500 Problem Statement", RFC 4925, July 2007. 502 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 503 "DHCPv6 Leasequery", RFC 5007, September 2007. 505 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 506 Stack Lite Broadband Deployments Following IPv4 507 Exhaustion", RFC 6333, August 2011. 509 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 510 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 511 RFC 6334, August 2011. 513 8.2. Informative References 515 [I-D.boucadair-intarea-nat-reveal-analysis] 516 Boucadair, M., Touch, J., Levis, P., and R. Penno, 517 "Analysis of Solution Candidates to Reveal a Host 518 Identifier in Shared Address Deployments", 519 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 520 progress), September 2011. 522 [I-D.boucadair-softwire-dslite-v6only] 523 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 524 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 525 Stack Lite in IPv6 Network", 526 draft-boucadair-softwire-dslite-v6only-01 (work in 527 progress), April 2011. 529 [I-D.xu-behave-stateful-nat-standby] 530 Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy 531 Requirements and Framework for Stateful Network Address 532 Translators (NAT)", 533 draft-xu-behave-stateful-nat-standby-06 (work in 534 progress), October 2010. 536 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 537 E. Lear, "Address Allocation for Private Internets", 538 BCP 5, RFC 1918, February 1996. 540 [RFC2983] Black, D., "Differentiated Services and Tunnels", 541 RFC 2983, October 2000. 543 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 544 via IPv4 Clouds", RFC 3056, February 2001. 546 [RFC3484] Draves, R., "Default Address Selection for Internet 547 Protocol version 6 (IPv6)", RFC 3484, February 2003. 549 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 550 (ICE): A Protocol for Network Address Translator (NAT) 551 Traversal for Offer/Answer Protocols", RFC 5245, 552 April 2010. 554 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 555 Infrastructures (6rd)", RFC 5569, January 2010. 557 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 558 Troan, "Basic Requirements for IPv6 Customer Edge 559 Routers", RFC 6204, April 2011. 561 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 562 Roberts, "Issues with IP Address Sharing", RFC 6269, 563 June 2011. 565 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 566 "Logging Recommendations for Internet-Facing Servers", 567 BCP 162, RFC 6302, June 2011. 569 Authors' Addresses 571 Yiu L. Lee 572 Comcast 573 One Comcast Center 574 Philadelphia, PA 19103 575 U.S.A. 577 Email: yiu_lee@cable.comcast.com 578 URI: http://www.comcast.com 580 Roberta Maglione 581 Telecom Italia 582 Via Reiss Romoli 274 583 Torino 10148 584 Italy 586 Email: roberta.maglione@telecomitalia.it 587 URI: 589 Carl Williams 590 MCSR Labs 591 Philadelphia 592 U.S.A. 594 Email: carlw@mcsr-labs.org 595 Christian Jacquenet 596 France Telecom 597 Rennes 598 France 600 Email: christian.jacquenet@orange-ftgroup.com 602 Mohamed Boucadair 603 France Telecom 604 Rennes 605 France 607 Email: mohamed.boucadair@orange-ftgroup.com