idnits 2.17.1 draft-ietf-softwire-dslite-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 : ---------------------------------------------------------------------------- == There are 2 instances 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 28, 2012) is 4258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 4 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 1, 2013 Telecom Italia 6 C. Williams 7 MCSR Labs 8 C. Jacquenet 9 M. Boucadair 10 France Telecom 11 August 28, 2012 13 Deployment Considerations for Dual-Stack Lite 14 draft-ietf-softwire-dslite-deployment-04 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 1, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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. Requirements language . . . . . . . . . . . . . . . . . . . . 3 59 3. AFTR Deployment Considerations . . . . . . . . . . . . . . . . 3 60 3.1. Interface Consideration . . . . . . . . . . . . . . . . . 3 61 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . . 3 62 3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Lawful Intercept Considerations . . . . . . . . . . . . . 4 64 3.5. Logging at the AFTR . . . . . . . . . . . . . . . . . . . 4 65 3.6. Blacklisting a shared IPv4 Address . . . . . . . . . . . . 5 66 3.7. AFTR's Policies . . . . . . . . . . . . . . . . . . . . . 6 67 3.8. AFTR Impacts on Accounting Process . . . . . . . . . . . . 6 68 3.9. Reliability Considerations of AFTR . . . . . . . . . . . . 7 69 3.10. Strategic Placement of AFTR . . . . . . . . . . . . . . . 7 70 3.11. AFTR Considerations for Geographically Aware Services . . 8 71 3.12. Impacts on QoS . . . . . . . . . . . . . . . . . . . . . . 8 72 3.13. Port Forwarding Considerations . . . . . . . . . . . . . . 9 73 3.14. DS-Lite Tunnel Security . . . . . . . . . . . . . . . . . 9 74 3.15. IPv6-only Network Considerations . . . . . . . . . . . . . 10 75 4. B4 Deployment Considerations . . . . . . . . . . . . . . . . . 10 76 4.1. DNS deployment Considerations . . . . . . . . . . . . . . 10 77 4.2. IPv4 Service Monitoring . . . . . . . . . . . . . . . . . 10 78 4.2.1. B4 Remote Management . . . . . . . . . . . . . . . . . 10 79 4.2.2. IPv4 Connectivity Check . . . . . . . . . . . . . . . 11 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Overview 91 Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that 92 enable operators to multiplex public IPv4 addresses while 93 provisioning only IPv6 to users. DS-Lite is designed to continue 94 offering IPv4 services while operators upgrading their network 95 incrementally to IPv6. DS-Lite combines IPv4-in-IPv6 [RFC2473] 96 softwire and NAT44 [RFC3022] to enable more than one user to share a 97 public IPv4 address. This document discusses various DS-Lite 98 deployment considerations for operators. 100 2. Requirements language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. AFTR Deployment Considerations 108 3.1. Interface Consideration 110 Address Family Transition Router (AFTR) is a network element that 111 deployed inside the operator's network. AFTR can be a standalone 112 device or embedded into a router. AFTR is the IPv4-in-IPv6 tunnel 113 termination point and the NAT44 device. It is deployed at the IPv4- 114 IPv6 network border where the tunnel interface is IPv6 and the 115 external NAT44 interface is IPv4. Although an operator can configure 116 a dual-stack interface for both functions, we recommend to configure 117 two individual interfaces (i.e. one dedicated for IPv4 and one 118 dedicated for IPv6) to segregate the functions. 120 3.2. MTU Considerations 122 DS-Lite is part tunneling protocol. Tunneling introduces overhead to 123 the packet and decreases the effective MTU size after encapsulation. 124 The DS-lite users may experience problems with applications such as 125 not being able to download Internet pages or transfer large file. To 126 mitigate the tunnel overhead, the access network may increase the MTU 127 size to account the necessary tunnel overhead. If simple IPv4-in- 128 IPv6 softwire [RFC2473] is used, the overhead is the size of an IPv6 129 header. If the access network MTU size is fixed and cannot be 130 changed, the B4 element and the AFTR must support fragmentation 131 defined in [RFC6333]. 133 3.3. Fragmentation 135 The IPv4-in-IPv6 tunnel is established between B4 and AFTR. When a 136 host behind the B4 element communicates with a remote peer, both end 137 nodes are not aware of the tunnel. For example, the peers may use 138 the MTU size associated with their connected interfaces. In fact, 139 the IPv4 packet isn't over-sized, it is the IPv6 encapsulation that 140 may cause the oversize of the encapsulating packets. So the tunnel 141 endpoints are responsible for handling the fragmentation. In 142 general, the Tunnel-Entry Point and Tunnel-Exit Point should fragment 143 and reassemble the oversized datagram. If the DF bit is set in the 144 IPv4 header, the B4 element should send an ICMP "Destination 145 Unreachable" with "Fragmentation Needed and Don't Fragment was Set" 146 and drop the packet. If the DF is unset in the IPv4 header, the B4 147 element should fragment the IPv6 packet after the encapsulation. 148 This mechanism is transport protocol agnostic and works for transport 149 protocol such as TCP and UDP over IP. 151 3.4. Lawful Intercept Considerations 153 Because of the IPv4-in-IPv6 tunneling scheme, interception of IPv4 154 sessions in DS-Lite framework is likely performed on the AFTR. 155 Subjects can be uniquely identified by the IPv6 address assigned to 156 the B4 element. If an operator is legally requested to intercept 157 packets of a subject, the AFTR should extract the IPv4 packets from 158 the IPv6 payload before sending it to the interception point. 160 Monitoring of a subject may require statically mapping the subject to 161 a certain range of ports of a single IPv4 address, to remove the need 162 to follow dynamic port mappings. A single IPv4 address, or some 163 range of ports for each address, might be set aside for monitoring 164 purposes to simplify such procedures. This requires creating a 165 static mapping of a B4 element's IPv6 address to a public IPv4 166 address and port range that are used for lawful intercept. 168 3.5. Logging at the AFTR 170 Timestamped logging is essential for back tracking specific users 171 when a problem is identified with one of the AFTR's NAT-ed addresses. 172 Such a problem is usually a misbehaving user in the case of a spammer 173 or a Deny-of-Service (DoS) source, or someone violating a usage 174 policy. Without time-specific logs of the address and port mappings, 175 a misbehaving user stays well hidden behind the AFTR. 177 In DS-Lite framework, each B4 element is provisioned with one or more 178 unique source IPv6 addresses. The AFTR uses the B4's tunnel IPv6 179 address to identify the B4 element. Thus, to uniquely identify a 180 specific user, the AFTR is required to log more than just IPv4 181 address. There are two types of logging: 183 o Source-Specific Log 185 o Destination-Specific Log 187 For Source-Specific Log, the AFTR must timestamped log the B4's IPv6 188 address, transport protocol, source IPv4 address after NAT-ed, and 189 source port. If a range of ports is dynamically assigned to a B4 190 element, the AFTR may create one log per range of ports to aggregate 191 number of log entries. For Destination-Specific Log, the AFTR must 192 create a timestamped log of the B4's IPv6 address, transport 193 protocol, source IPv4 address after NAT-ed, source port, destination 194 address and destination port. 196 Destination-Specific Log is session-based, the operators can't really 197 aggregate log entries. When using Destination-Specific Log, the 198 operator must be careful of the large number of log entries created 199 by the AFTR. Destination-Specific Log may raise privacy concerns. 200 Operators should apply the same privacy policies for both regular and 201 DS-Lite users. 203 Depedning on the rate of NAT table changes, real-time logging can be 204 demanding to the AFTR if AFTR must send a log message per NAT entry 205 change to the syslog server in real-time. If operators requires only 206 near real-time logs, they may configure the AFTR to log changes 207 locally and send the logs in a batch file in a pre-configured 208 interval (e.g. every 5 minutes). The files may be compressed before 209 transferring to better utilize bandwidth and storage. Other 210 optimizaitons are also under consideration such as AFTR pre- 211 allocating a set of ports to users. After creates only one log entry 212 when a user allocates the port-set instead of log per port 213 allocation. 215 3.6. Blacklisting a shared IPv4 Address 217 AFTR is a NAT device. It enables multiple users to share a single 218 public IPv4 address. [RFC6269] discusses some considerations when 219 sharing an IPv4 address. When a public IPv4 address is blacklisted 220 by a remote peer, this may affect multiple users. Internet hosts 221 such as servers must no longer rely solely on IP address to identify 222 an abused user. The server should combine the information stored in 223 the transport layer (e.g. source port) and application layer (e.g. 224 HTTP) to identify an abused user [RFC6302]. 225 [I-D.boucadair-intarea-nat-reveal-analysis] analyzes different 226 approaches to identify a user in a shared address environment. 228 3.7. AFTR's Policies 230 There are two types of AFTR polices: 232 o Outgoing Policies 234 o Incoming Policies 236 The outgoing policies should be implemented on the AFTR's internal 237 interface connected to the B4 elements. The policies may include 238 Access Control List (ACL) and Qualify of Service (QoS) settings. For 239 example: the AFTR may only accept B4's connections originated from 240 the IPv6 prefixes configured in the AFTR. The AFTR may also give 241 priority to the packets marked by certain DSCP values [RFC2475]; the 242 AFTR may also limit the rate of port allocation for a single B4's 243 IPv6 address. 245 An operator may create multiple outgoing polices in the AFTR, each 246 identified by a softwire. When provisioning a user, the system will 247 pass the softwire identifier associated to a specific incoming policy 248 to the user. Two standardized mechanisms to pass softwire identifier 249 to the B4 element are DHCPv6 [RFC6333] and RADIUS [RFC6519]. 250 Outgoing policies could be applied to an individual B4 element or to 251 a set of B4 elements. 253 The incoming policies should be implemented on the AFTR's external 254 interface connected to the IPv4 network. Similar to the outgoing 255 policies, the incoming policies may include ACL and QoS settings. 256 Incoming policies are usually more general and generic. They usually 257 applied to all users rather than to an individual user. 259 3.8. AFTR Impacts on Accounting Process 261 DS-Lite introduces challenges to IPv4 accounting process. In a 262 typical broadband access scenario (e.g. DSL or Cable), the B4 263 element is embedded in the Residential Gateway and the edge router 264 (e.g. BRAS or CMTS) is the IPv6 edge router. The edge router is 265 usually responsible for IPv6 accounting and the subscriber management 266 functions such as authentication, authorization and accounting. 267 However, given the fact that IPv4 traffic is encapsulated in an IPv6 268 packet at the B4 and only decapsulated at the ATFR, the edge router 269 will require additional function to collect IPv4 accounting 270 information. If DS-lite is the only application using IP-in-IP 271 protocol, the edge router could check the IPv6 Next Header field in 272 the IPv6 header and identify the protocol type (i.e. 0x04) and 273 collect IPv4 accouting information. 275 Alternatively, AFTR is a logical place to perform IPv4 accounting, 276 but it will potentially introduce some additional complexity because 277 the AFTR does not have detailed customer identity information. The 278 accounting process at the AFTR is only necessary if the operator 279 requires separating per user accounting records for IPv4 and IPv6 280 traffic. If the per user IPv6 accounting records, collected by the 281 edge router, are sufficient, the additional complexity of enabling 282 IPv4 accounting at the ATFR is not required. It is important to 283 notice that, since the IPv4 traffic is encapsulated in IPv6 packets, 284 the data collected by the edge router for IPv6 traffic already 285 contain the total amount of traffic (i.e. IPv4 and IPv6). 287 Even if detailed accounting records collection for IPv4 traffic may 288 not be required, it would be useful for an operator in some scenarios 289 to have information that is generated by the edge router for the IPv6 290 traffic and can be used to identify the AFTR who is handling the IPv4 291 traffic for that user. This can be achieved by adding additional 292 information the IPv6 accounting records. For example: operators can 293 use RADIUS attribute information specified in [RFC6519] or new 294 attribute to be speciified in Internet Protocol Detailed Record 295 (IPDR). 297 3.9. Reliability Considerations of AFTR 299 The operator can use techniques such as various types of clusters to 300 achieve high availability of the IPv4 service. High availability 301 techniques include the cold standby mode. In this mode the AFTR 302 states are not replicated from the Primary AFTR to the Backup AFTR. 303 When the Primary AFTR fails, all the existing established sessions 304 will be flushed out. The internal hosts are required to re-establish 305 sessions with the external hosts. Another high availability option 306 is the hot standby mode. In this mode the AFTR keeps established 307 sessions while failover happens. AFTR states are replicated on-the- 308 fly from the Primary AFTR to the Backup AFTR. When the Primary AFTR 309 fails, the Backup AFTR will take over all the existing established 310 sessions. In this mode the internal hosts are not required to re- 311 establish sessions with the external hosts. The final option is to 312 deploy a mode in between these two whereby only selected sessions 313 such as critical protocols are replicated. Criteria for sessions to 314 be replicated on the backup would be explicitly configured on the 315 AFTR devices of a redundancy group. 317 3.10. Strategic Placement of AFTR 319 In DS-lite, IPv4 traffic from B4 must pass through the AFTR to reach 320 the IPv4 Internet. Managing large numbers of tunnels and a large NAT 321 table could be resource intensive (e.g. CPU and memory), so the 322 placement of the AFTR could affect the traffic flows in the access 323 network and have operation implications. In general, there are two 324 placement models to deploy AFTR. Model One is to deploy the AFTR in 325 the edge of the network to cover a small region. Model Two is to 326 deploy the AFTR in the core of network to cover a large region. 328 When an operator considers where to deploy the AFTR, it must make 329 trade-offs. AFTR in Model One serves few B4 elements, thus, it 330 requires less powerful AFTR. Moreover, the traffic flows are more 331 evenly distributed to the AFTRs. However, it requires deploying more 332 AFTRs to cover the entire network. Often the operation cost 333 increases proportionally to the number of network equipment. 335 AFTR in Model Two covers a large area, thus, it serves more B4 336 elements. The operator could deploy only few AFTRs to support the 337 entire subscriber base. However, this model requires more powerful 338 AFTR to sustain the load at peak hours. Since the AFTR would support 339 B4 elements from different regions, the AFTR would be deployed closer 340 to the core network. 342 DS-Lite framework can be incrementally deployed. An operator may 343 consider to start with Model Two. When the demand increases, they 344 could push the AFTR closer to the edge which would effectively become 345 Model One. 347 3.11. AFTR Considerations for Geographically Aware Services 349 By centralizing public IPv4 addresses, each address no longer 350 represents a single machine, a single household, or a single small 351 office. The address now represents hundreds of machines, homes, and 352 offices related only in that they are behind the same AFTR. 353 Identification by IP address becomes more difficult and thus 354 applications that assume such geographic information may not work as 355 intended. Placement of AFTR could impact the geographical aware 356 services. To minimize the impact, an operator could deploy AFTR 357 closer to users so that existing location based assumptions of the 358 clients source IP address by geographically aware servers can be 359 maintained. Another possibility is that the applications could rely 360 on location information such as GPS co-ordination to identify the 361 user's location. This technique is commonly used in mobile 362 deployment where the mobile handheld devices are probably usually 363 behind a NAT device. 365 3.12. Impacts on QoS 367 Operators commonly use DSCP [RFC2475] to classify and prioritize 368 different types of traffic. DS-Lite tunnel can be seen as a 369 particular case of uniform conceptual tunnel model described in 370 section 3.1 of [RFC2983]. The uniform model views an IP tunnel as 371 just a necessary mechanism to forward traffic to its destination, but 372 the tunnel has no significant impact on traffic conditioning. In 373 this model, any packet has exactly one DS Field that is used for 374 traffic conditioning at any point and it is the field in the 375 outermost IP header. In DS-Lite model this is the Traffic Class 376 field in IPv6 header. According to [RFC2983] implementations of this 377 model copy the DS value to the outer IP header at encapsulation and 378 copy the outer header's DSCP value to the inner IP header at 379 decapsulation. Applying the described model to DS-Lite scenario, it 380 is recommended that the AFTR copies the DSCP value in the IPv4 header 381 to the IPv6 header after the encapsulation for the downstream traffic 382 and similarly the B4 copies the DSCP value in the IPv4 header to the 383 IPv6 header after the encapsulation for the upstream traffic. 385 3.13. Port Forwarding Considerations 387 Some applications require the B4 to accept incoming requests. When 388 the remote host is on IPv4, the incoming request will be directed 389 towards the B4's IPv4 address. Some applications use UPnP-IGD (e.g., 390 popular gaming consoles) or ICE [RFC5245] (e.g., SIP, Yahoo!, Google, 391 Microsoft chat networks) to request incoming ports. Some 392 applications rely on ALGs or manual port configuration to reserve a 393 port in the NAT. In usual DS-Lite deployment, B4 does not own a 394 dedicated public IPv4 address or all the available ports, so it must 395 coordinate with its serving AFTR and the applications to reserve the 396 incoming ports. Port Control Protocol (PCP) [I-D.ietf-pcp-base] is 397 designed to address this issue. 399 3.14. DS-Lite Tunnel Security 401 Section 11 of [RFC6333] describes security issues associated to DS- 402 Lite mechanism. To restrict the service offered by AFTR only to 403 registered customers, an operator can implement IPv6 ingress filter 404 on the AFTR's tunnel interface to accept only the IPv6 prefixes 405 defined in the filter. This approach requires knowing in advance the 406 IPv6 prefixes provisioned to the customers for the softwire in order 407 to configure the filter. 409 Using DHCPv6 Leasequery defined in [RFC5007] is another option of 410 achieving the same goal and providing some form of access control to 411 AFTR. When the AFTR receives a packet from an unknown IPv6 prefix, 412 it issues a DHCPv6 Leasequery based on the DUID to the DHCPv6 server 413 in order to verify if that prefix was previously provisioned by the 414 DHCPv6 server to the specific DUID. If known, the DHCPv6 server will 415 reply with the IPv6 prefix and the associated lease. If both 416 prefixes match, the ATFR accepts the packet otherwise it drops the 417 packet and denies the service. 419 3.15. IPv6-only Network Considerations 421 In environments where the operator wants to deploy AFTR in the IPv6- 422 only network, the AFTR nodes may not have direct IPv4 connectivity. 423 In this scenario the operator extends the IPv6-only boundary to the 424 border of the network and only the border routers have IPv4 425 connectivity. For both scalability and performance purposes, AFTR is 426 located in the IPv6-only network closer to B4 elements. In this 427 scenario the AFTR has only IPv6 connectivity and must be able to send 428 and receive IPv4 packets. Enhancements to the DS-Lite AFTR are 429 required to achieve this. [I-D.boucadair-softwire-dslite-v6only] 430 describes such issues and enhancements to DS-Lite in IPv6-only 431 deployments. 433 4. B4 Deployment Considerations 435 In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs 436 the IPv6 address of the AFTR element. This IPv6 address can be 437 configured using a variety of methods, ranging from an out-of-band 438 mechanism, manual configuration, DHCPv6 option to RADIUS. If an 439 operator uses DHCPv6 to provision the B4, the B4 element must 440 implement the DHCPv6 option defined in [RFC6334]. If an operator 441 uses RADIUS to provision the B4, the B4 element must implement 442 [RFC6519]. 444 4.1. DNS deployment Considerations 446 [RFC6333] recommends the B4 element should send DNS queries to an 447 external recursive resolver over IPv6. The B4 element should 448 implement proxy resolver that will proxy DNS query from IPv4 449 transport to the DNS server in the IPv6 network. Alternatively, the 450 DHCPv4 server on the B4 is configured to give its clients an IPv4 451 address of an external DNS recursive resolver. Then, the B4 can be 452 statically configured to tunnel all DNS packets to the external 453 resolver over IPv6 to the AFTR. Note that there is no effective way 454 to provision an IPv4 DNS address to the B4 over IPv6, this may create 455 complexity in B4 provisioning. Moreover, this will increase load to 456 AFTR by creating short-live entries in the NAT table, this alternate 457 solution is likely to be unsatisfactory in a production environment. 458 It should be used in a testing or demonstration environment. 460 4.2. IPv4 Service Monitoring 462 4.2.1. B4 Remote Management 464 B4 is connected to IPv6 access network to offer IPv4 services. When 465 users experience IPv4 connectivity issue, operators must be able to 466 remotely access (e.g. TR-069) the B4 element to verify its B4's 467 configuration and status. Operators should access B4 elements using 468 native IPv6. Operators should not access B4 over the softwire. 470 4.2.2. IPv4 Connectivity Check 472 DS-Lite framework provides IPv4 services over IPv6 access network. 473 Operators must be able to check the IPv4 connectivity from the B4 474 element to its AFTR. AFTR should be configured with an IPv4 address 475 to enable PING test and traceroute test. An operator may assign the 476 same IPv4 address (e.g. 192.0.0.2/32) to all AFTRs. This IPv4 477 address only used to respond to the requests from the B4 elements 478 over the softwire. IANA allocates 192.0.0.0/29 [RFC6333] which can 479 be used for this purpose. 481 5. Security Considerations 483 This document does not present any new security issues. [RFC6333] 484 discusses DS-Lite related security issues. General NAT security 485 issues are not repeated here. 487 Some of the security issues result directly from sharing routable 488 IPv4 addresses. Addresses and timestamps are often used to identify 489 a particular user, but with shared addresses, more information (i.e., 490 protocol and port numbers) is needed. This impacts software used for 491 logging and tracing spam, denial of service attacks, and other 492 abuses. Devices on the customer's side may try to carry out general 493 attacks against systems on the global Internet or against other 494 customers by using inappropriate IPv4 source addresses inside the 495 tunneled traffic. The AFTR needs to protect against such abuse. One 496 customer may try to carry out a denial of service attack against 497 other customers by monopolizing the available port numbers. The AFTR 498 needs to ensure equitable access. At a more sophisticated level, a 499 customer may try to attack specific ports used by other customers. 500 This may be more difficult to detect and to mitigate without a 501 complete system for authentication by port numbers, which would 502 represent a huge security requirement. 504 6. Conclusion 506 DS-Lite provides new functionality to transition IPv4 traffic to IPv6 507 addresses. As the supply of unique IPv4 addresses diminishes, 508 operators can now allocate new subscriber homes IPv6 addresses and 509 IPv6-capable equipment. DS-Lite provides a means for the private 510 IPv4 addresses behind the IPv6 equipment to reach the public IPv4 511 network. 513 This document discusses the issues that arise when deploying DS-Lite 514 in various deployment modes. Hence, this document can be a useful 515 reference for operators and network designers. Deployment 516 considerations of the B4, AFTR and DNS have been discussed and 517 recommendations for their usage have been documented. 519 7. Acknowledgement 521 Thanks to Mr. Nejc Skoberne and Dr. Maoke Chen for their through 522 review and helpful comments. We also want to thank Mr. Hu Jie for 523 sharing his DS-Lite deployment experience to us. He gave us 524 recommendations what his company learned while testing DS-Lite in the 525 production network. 527 8. IANA Considerations 529 This memo includes no request to IANA. 531 9. References 533 9.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 539 Stack Lite Broadband Deployments Following IPv4 540 Exhaustion", RFC 6333, August 2011. 542 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 543 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 544 RFC 6334, August 2011. 546 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 547 Stack Lite", RFC 6519, February 2012. 549 9.2. Informative References 551 [I-D.boucadair-intarea-nat-reveal-analysis] 552 Boucadair, M., Touch, J., Levis, P., and R. Penno, 553 "Analysis of Solution Candidates to Reveal a Host 554 Identifier in Shared Address Deployments", 555 draft-boucadair-intarea-nat-reveal-analysis-04 (work in 556 progress), September 2011. 558 [I-D.boucadair-softwire-dslite-v6only] 559 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 560 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 561 Stack Lite in IPv6 Network", 562 draft-boucadair-softwire-dslite-v6only-01 (work in 563 progress), April 2011. 565 [I-D.ietf-pcp-base] 566 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 567 Selkirk, "Port Control Protocol (PCP)", 568 draft-ietf-pcp-base-26 (work in progress), June 2012. 570 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 571 IPv6 Specification", RFC 2473, December 1998. 573 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 574 and W. Weiss, "An Architecture for Differentiated 575 Services", RFC 2475, December 1998. 577 [RFC2983] Black, D., "Differentiated Services and Tunnels", 578 RFC 2983, October 2000. 580 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 581 Address Translator (Traditional NAT)", RFC 3022, 582 January 2001. 584 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 585 "DHCPv6 Leasequery", RFC 5007, September 2007. 587 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 588 (ICE): A Protocol for Network Address Translator (NAT) 589 Traversal for Offer/Answer Protocols", RFC 5245, 590 April 2010. 592 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 593 Roberts, "Issues with IP Address Sharing", RFC 6269, 594 June 2011. 596 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 597 "Logging Recommendations for Internet-Facing Servers", 598 BCP 162, RFC 6302, June 2011. 600 Authors' Addresses 602 Yiu L. Lee 603 Comcast 604 One Comcast Center 605 Philadelphia, PA 19103 606 U.S.A. 608 Email: yiu_lee@cable.comcast.com 609 URI: http://www.comcast.com 611 Roberta Maglione 612 Telecom Italia 613 Via Reiss Romoli 274 614 Torino 10148 615 Italy 617 Email: roberta.maglione@telecomitalia.it 618 URI: 620 Carl Williams 621 MCSR Labs 622 U.S.A. 624 Email: carlw@mcsr-labs.org 626 Christian Jacquenet 627 France Telecom 628 Rennes 629 France 631 Email: christian.jacquenet@orange.com 633 Mohamed Boucadair 634 France Telecom 635 Rennes 636 France 638 Email: mohamed.boucadair@orange.com