idnits 2.17.1 draft-ietf-softwire-dslite-deployment-08.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 (January 17, 2013) is 4110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-04 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 3 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: July 21, 2013 Telecom Italia 6 C. Williams 7 MCSR Labs 8 C. Jacquenet 9 M. Boucadair 10 France Telecom 11 January 17, 2013 13 Deployment Considerations for Dual-Stack Lite 14 draft-ietf-softwire-dslite-deployment-08 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 July 21, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. AFTR Deployment Considerations . . . . . . . . . . . . . . . . 3 59 2.1. Interface Consideration . . . . . . . . . . . . . . . . . 3 60 2.2. MTU and Fragmentation Considerations . . . . . . . . . . . 4 61 2.3. Logging at the AFTR . . . . . . . . . . . . . . . . . . . 4 62 2.4. Blacklisting a Shared IPv4 Address . . . . . . . . . . . . 5 63 2.5. AFTR's Policies . . . . . . . . . . . . . . . . . . . . . 5 64 2.5.1. Outgoing Policy . . . . . . . . . . . . . . . . . . . 5 65 2.5.2. Incoming Policy . . . . . . . . . . . . . . . . . . . 6 66 2.6. AFTR Impacts on Accounting Process . . . . . . . . . . . . 6 67 2.7. Reliability Considerations of AFTR . . . . . . . . . . . . 7 68 2.8. Strategic Placement of AFTR . . . . . . . . . . . . . . . 8 69 2.9. AFTR Considerations for Geographically Aware Services . . 8 70 2.10. Impacts on QoS Policy . . . . . . . . . . . . . . . . . . 9 71 2.11. Port Forwarding Considerations . . . . . . . . . . . . . . 9 72 2.12. DS-Lite Tunnel Security . . . . . . . . . . . . . . . . . 10 73 2.13. IPv6-only Network Considerations . . . . . . . . . . . . . 10 74 3. B4 Deployment Considerations . . . . . . . . . . . . . . . . . 11 75 3.1. DNS Deployment Considerations . . . . . . . . . . . . . . 11 76 3.2. IPv4 Service Monitoring . . . . . . . . . . . . . . . . . 11 77 3.2.1. B4 Remote Management . . . . . . . . . . . . . . . . . 11 78 3.2.2. IPv4 Connectivity Check . . . . . . . . . . . . . . . 12 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Overview 89 Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that 90 enable operators to multiplex public IPv4 addresses while 91 provisioning only IPv6 to users. DS-Lite is designed to continue 92 offering IPv4 services while operators upgrading their network 93 incrementally to IPv6. DS-Lite combines IPv4-in-IPv6 softwire 94 [RFC2473] and NAT44 [RFC3022] to enable more than one user to share a 95 public IPv4 address. 97 While Appendix A of [RFC6333] explains how to deploy DS-Lite within 98 specific scenarios, the purpose of this document is to describe 99 problems that arise when deploying DS-Lite and what guidance should 100 be taken to mitigate those issues. The information is based on real 101 deployment experience and compiled in one comprehensive document so 102 that operators aren't required to search through various RFCs 103 deciding which sections are applicable and impact their DS-Lite 104 deployment. 106 2. AFTR Deployment Considerations 108 2.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. The B4 element [RFC6333] is a 116 function implemented on a dual-stack capable node, either a host 117 device or a home gateway that creates a tunnel to an AFTR. Although 118 an operator can configure both softwire tunnel termination and 119 interface for NAT44 functions on a single physical interface (yet 120 logically separated), there are scenarios we recommend to configure 121 two individual interfaces (i.e. one dedicated for IPv4 and one 122 dedicated for IPv6) to segregate the functions. 124 o The access network between the B4 and AFTR is an IPv6-only network 125 and the network between AFTR and IPv4 network is either IPv4-only 126 network. In this deployment scenario, the AFTR interface to the 127 IPv6-only network and the interface to the IPv4 network should use 128 two physical interfaces on AFTR. 130 o Operators may use Operations Support System (OSS) tools (e.g., 131 Multi Router Traffic Grapher) to collect interface data packet 132 count information. If an operator wants to separate the softwire 133 function and NAT44 function on different physical interfaces for 134 collecting data packet count and the AFTR does not support packet 135 count for logical interfaces, they should use two physical 136 interfaces on AFTR. 138 2.2. MTU and Fragmentation Considerations 140 DS-Lite is part tunneling protocol. Tunneling introduces overhead to 141 the packet and decreases the effective MTU size after encapsulation. 142 The DS-lite users may experience problems with applications such as 143 not being able to download Internet pages or transfer large files. 145 Since fragmentation and reassembly is not optimal, the operator 146 should do everything possible to eliminate the need for it. If the 147 operator uses simple IPv4-in-IPv6 softwire [RFC2473], it is 148 recommended that the MTU size of the IPv6 network between the B4 and 149 the AFTR account for the additional overhead (40 bytes). If the 150 access network MTU size is fixed and cannot be changed, the operator 151 should be aware that the B4 element and the AFTR must support 152 fragmentation as defined in [RFC6333]. The operator should also be 153 aware that reassembly at Tunnel Exit-Point is resource intensive as a 154 large number of B4 may terminate on the same AFTR. Scalability of 155 the AFTR is advised in this scenario. 157 2.3. Logging at the AFTR 159 Source-Specific Log is essential for back tracking specific users 160 when a problem is identified with one of the AFTR's NAT-ed addresses. 161 Source-specific log contains the B4 IPv6 source address, transport 162 protocol, source port, and source IPv4 address after NAT-ed. Using 163 the Source-specific log, operators can uniquely identify a specific 164 user when a DS-Lite user experiences problem to access IPv4 network. 165 To maximize IPv4 shared radio, an operator may configure a short 166 timeout value for NAT44 entries. This will result a large numbers of 167 log created by the AFTR. For operators who desire to aggregate the 168 logs, they can configure AFTR to pre-allocate a range of ports to 169 each user. This range of ports will be used in the NAT44 function 170 and the AFTR will create one log entry for the whole port-range. 171 This aggregation can significantly reduce the log size for Source- 172 specific logging. 174 Some operators may require to log both source and destination 175 information for user's connections. This is called Destination- 176 Specific Log. Destination-specific log contains the B4's IPv6 177 address, transport protocol, source port, source IPv4 address after 178 NAT-ed, destination port and destination IPv4 address. Destination- 179 specific log is session-based, the operators should be aware that 180 they will not be able to aggregate log entries. When using 181 destination-specific log, the operator must be careful of the large 182 number of log entries created by the AFTR. Some AFTR implementations 183 may keep the logs in main memory. This may be CPU and memory 184 resource intensive. We suggest the operators must configure the AFTR 185 to periodically send logs to storage facility and then purge them 186 from AFTR. 188 2.4. Blacklisting a Shared IPv4 Address 190 AFTR is a NAT device. It enables multiple users to share a single 191 public IPv4 address. [RFC6269] discusses some considerations when 192 sharing an IPv4 address. When a public IPv4 address is blacklisted 193 by a remote peer, this may affect multiple B4 elements sharing the 194 same IPv4 address. Operators deploying DS-Lite should be aware that 195 Internet hosts may rely solely on source IP address to identify an 196 abusive household and may not be aware that a given single IPv4 197 address is actually shared by multiple households. A content 198 provider may block services for a shared IPv4 address and this will 199 impact all households sharing this particular IPv4 address. The 200 operator may receive calls of service outage and will need to take 201 appropriate actions. Such corrective actions include but not limited 202 to notifying the content provider to combine the IPv4 address with 203 transport (e.g., TCP) and application protocol (e.g., HTTP) to 204 identify abusive household. [RFC6302]. 205 [I-D.ietf-intarea-nat-reveal-analysis] analyzes different approaches 206 to identify a user in a shared address environment. 208 2.5. AFTR's Policies 210 There are two types of AFTR policies: 212 o Outgoing Policies apply to packets originating from B4 to AFTR. 213 These policies should be provisioned on the AFTR's IPv6 interface 214 connected to the B4 elements. 216 o Incoming Policies apply to packets originating from IPv4 network 217 to B4s. These policies should be provisioned on the IPv4 218 Interface connected to the IPv4 network. 220 2.5.1. Outgoing Policy 222 Outgoing policies may include Access Control List (ACL) and Qualify 223 of Service (QoS) settings. These policies control the packets from 224 B4 elements to the AFTR. For example, the operator may configure the 225 AFTR only to accept B4's connections originated from specific IPv6 226 prefixes configured in the AFTR. More discussion of this use case 227 can be found in Section 2.12. An operator may configure the AFTR to 228 give priority to the packets marked by certain DSCP values [RFC2475]. 229 Furthermore, an AFTR may also apply outgoing policy to limit the rate 230 of port allocation for a single B4's IPv6 address. 232 Some operators offer different service level agreements (SLA) to 233 users to meet their requirements. Some users may require more ports 234 and some may require different service priority. In this deployment 235 scenario, the operator can implement outgoing policies specified to a 236 user's B4 element or a group of B4 elements sharing the same 237 policies. 239 2.5.2. Incoming Policy 241 Similar to Outgoing Policy, Incoming Policy may also include ACL and 242 QoS settings. Outgoing Policy controls packets coming from IPv4 243 network to the B4 elements. Incoming packets are normally treated 244 equally, so these policies are globally applied. For example, an 245 operator wants to use a pre-defined DSCP value to signal the IPv6 246 access network to apply certain traffic policies. In this deployment 247 scenario, the operator can configure the AFTR to mark the incoming 248 packets with the pre-defined DSCP value. This policy will apply to 249 all incoming packets from the IPv4 network. 251 2.6. AFTR Impacts on Accounting Process 253 This section discusses IPv4 and IPv6 traffic accounting in DS-Lite 254 environment. In a typical broadband access scenario (e.g. DSL or 255 Cable), the B4 element is embedded in the Residential Gateway and the 256 edge router (e.g., Broadband Network Gateway or Cable Modem 257 Termination System) is the IPv6 edge router. The edge router is 258 usually responsible for IPv6 accounting and the user management 259 functions such as authentication, authorization and accounting (AAA). 260 However, given the fact that IPv4 traffic is encapsulated in an IPv6 261 packet at the B4 and only decapsulated at the ATFR, the edge router 262 will require additional function to associate IPv4 accounting 263 information to the B4 IPv6 address. If DS-lite is the only 264 application using IPv4-in-IPv6 protocol in the IPv6 access network, 265 the operator can configure the edge router to check the IPv6 Next 266 Header field in the IPv6 header and identify the protocol type (i.e. 267 0x04) and collect IPv4 accounting information. 269 Alternatively, AFTR may perform accounting for IPv4 traffic. 270 However, operators must be aware that this will introduce some 271 challenges especially in DSL deployment. In DSL deployment, the AAA 272 transaction normally happens between the edge router (i.e., Broadband 273 Network Gateway) and AAA server. [RFC6333] does not require the AFTR 274 to interact with the AAA server or edge router. Thus, AFTR may not 275 have the AAA parameters (e.g., Account Session ID) associated to 276 users to generate IPv4 accounting record. The accounting process at 277 the AFTR is only necessary if the operator requires separating per 278 user accounting records for IPv4 and IPv6 traffic. If the per user 279 IPv6 accounting records, collected by the edge router, are 280 sufficient, and the additional complexity of enabling IPv4 accounting 281 at the ATFR is not required. It is important to notice that, since 282 the IPv4 traffic is encapsulated in IPv6 packets, the data collected 283 by the edge router for IPv6 traffic already contain the total amount 284 of traffic (i.e. IPv4 and IPv6). 286 Even if detailed accounting records collection for IPv4 traffic may 287 not be required, it would be useful for an operator in some scenarios 288 to have information the edge router generates that for the IPv6 289 traffic and can be used to identify the AFTR who is handling the IPv4 290 traffic for that user. This can be achieved by adding additional 291 information to the IPv6 accounting records. For example: operators 292 can use RADIUS attribute information specified in [RFC6519] or a new 293 attribute to be specified in Internet Protocol Detailed Record 294 (IPDR). 296 2.7. Reliability Considerations of AFTR 298 For robustness, reliability and load distribution purposes, operators 299 may deploy multiple AFTRs. In such case, the same IPv6 prefixes and 300 algorithm to build the tunneling mechanisms will be configured on 301 those AFTRs. In [RFC6333] A.3 mentions High Availability (HA) is the 302 operator's responsibility. Since DS-lite is a stateful mechanism, 303 all requirements for load-balancing and failover mechanism apply. 304 There are many ways to implement HA in stateful mechanism, most 305 common are Cold Standby mode and Hot Standby mode. More discussion 306 on deploying of these two modes for NAT can be found in 307 [I-D.xu-behave-stateful-nat-standby] In Cold Standby mode the AFTR 308 states are not replicated from the Primary AFTR to the Backup AFTR. 309 When the Primary AFTR fails, all the existing established sessions 310 will be flushed out. The internal hosts are required to re-establish 311 sessions with the external hosts. In Hot Standby mode the user's 312 states are replicated on-the-fly from the Primary AFTR to the Backup 313 AFTR. When the Primary AFTR fails, the Backup AFTR will take over 314 all the existing established sessions. In this mode the internal 315 hosts are not required to re-establish sessions with the external 316 hosts. 318 For operators, the decision to use Cold Standby mode or Hot Standby 319 mode depends on the trade-off between capital cost and operational 320 cost. Cold Standby mode does not require a Backup Standby AFTR to 321 synchronize user states. This simplifies the operational model. 322 When the Primary AFTR went down, any AFTR with extra capacity could 323 take over. Hot Standby mode provides a smoother failover experience 324 to users, the cost for the operators is more careful failover 325 planning. For most deployment scenarios, we believe that Cold 326 Standby mode should be sufficient enough and thus recommended. 328 2.8. Strategic Placement of AFTR 330 In DS-Lite environment, AFTR is the logical next-hop router of the B4 331 elements to access IPv4 network, so the placement of the AFTR will 332 affect the traffic flows in the access network and overall network 333 design. In general, there are two placement models to deploy AFTR. 334 Model One is to deploy the AFTR in the edge of the network to cover a 335 small region. Model Two is to deploy the AFTR in the core of network 336 to cover a large region. 338 When an operator considers where to deploy the AFTR, it must make 339 trade-offs. AFTR in Model One serves fewer B4 elements, thus, it 340 requires less powerful AFTR. Moreover, the traffic flows are more 341 evenly distributed to the AFTRs. However, it requires deploying more 342 AFTRs to cover the entire network. Often the operation cost 343 increases proportionally with to the number of network equipment. 345 AFTR in Model Two covers a larger area, thus, it serves more B4 346 elements. The operator could deploy only few AFTRs to support the 347 entire user base. However, this model requires more powerful AFTR to 348 sustain the load at peak hours. Since AFTR would support B4 elements 349 from different regions, AFTR would be deployed closer to the core 350 network. 352 DS-Lite framework can be incrementally deployed. An operator may 353 consider to start with Model Two. When the demand increases, the 354 operator could push the AFTR closer to the edge, which would 355 effectively become Model One. 357 2.9. AFTR Considerations for Geographically Aware Services 359 By centralizing public IPv4 addresses in AFTR, remote services can no 360 longer rely on an IPv4 address and IPv4 routing information to derive 361 a user's geographical information. For example, the IPv6 access 362 network and the AFTR may be in two different cities. If the remote 363 services rely on the IPv4 address to locate a user, they may have 364 thought the user was in a different city. [RFC6269] Section 7 365 describe the problem in more details. Applications could explicitly 366 ask users to enter location information such as postal code or 367 telephone number before offering geographical service. In contrast, 368 applications could use HELD [RFC5985] to get the location information 369 from the Location Information Server and give this information to the 370 remote peer. [RFC6280] describes an architecture to enable location- 371 based services. However to mitigate the impact, we recommend 372 operators to deploy AFTR as close to users as possible. 374 2.10. Impacts on QoS Policy 376 This section describes the application of [RFC2983] to DS-Lite 377 deployment model. Operators must ensure that the QoS policy that is 378 in place operates properly within the DS-Lite deployment. In this 379 regard, operators commonly use DSCP [RFC2475] to classify and 380 prioritize different types of traffic in their networks. DS-Lite 381 tunnel can be seen as a particular case of uniform conceptual tunnel 382 model described in section 3.1 of [RFC2983]. The uniform model views 383 an IP tunnel as just a necessary mechanism to forward traffic to its 384 destination, but the tunnel has no significant impact on traffic 385 conditioning. In this model, any packet has exactly one DSCP Field 386 that is used for traffic conditioning at any point and it is the 387 field in the outermost IP header. In DS-Lite model this is the 388 Traffic Class field in IPv6 header. According to [RFC2983] 389 implementations of this model copy the DSCP value to the outer IP 390 header at encapsulation and copy the outer header's DSCP value to the 391 inner IP header at decapsulation. 393 Operators should use this model by provisioning the network such that 394 the AFTR copies the DSCP value in the IPv4 header to the Traffic 395 Class field in the IPv6 header after the encapsulation for the 396 downstream traffic. Similarly the B4 copies the DSCP value in the 397 IPv4 header to the Traffic Class field to the IPv6 header after the 398 encapsulation for the upstream traffic. Traffic identification and 399 classification can be done by examining the outer IPv6 header in the 400 IPv6 access network. 402 2.11. Port Forwarding Considerations 404 Some applications behind the B4 element require the B4 element to 405 accept incoming requests. If the remote application wants to 406 communicate to the application behind the B4 element, the remote 407 application must know both the NAT-ed IPv4 address used by the B4 408 element and the IPv4 destination port. Some applications use 409 Universal Plug and Play (UPnP) (e.g., popular gaming consoles) or ICE 410 [RFC5245] to request incoming ports. Some applications rely on 411 Application Level Gateway (ALG) or manual port configuration to 412 reserve a port in the NAT. For the DS-Lite deployment scenario 413 whereby the B4 does not own a dedicated public IPv4 address or all 414 the available ports, the operator will manage port-forwarding in the 415 serving AFTR. Operators may use Port Control Protocol (PCP) 416 [I-D.ietf-pcp-base] as guidance to provide port-forwarding service. 417 Operators will deploy PCP client in the B4 elements. PCP permits PCP 418 server to be deployed in a standalone server. However, we recommend 419 the operators to consider deploying the PCP server in the AFTR. This 420 will ease the overhead to design a global configuration for PCP 421 server for many AFTRs because each PCP server will be dedicated to 422 the collocated AFTR. 424 When sharing an IPv4 address, not all the ports are available to a 425 user. Some restricted ports (i.e., 0-1023) are well-known such as 426 TCP port 25 and 80. Many users may want to be provisioned with the 427 restricted ports. For fairness, we recommend operators to configure 428 the AFTR not to allocate the restricted ports to regular DS-Lite 429 users. This operation model ensures that DS-lite users will have 430 uniform configuration, which can simplify provisioning and operation. 431 For users who want to use the restricted ports, operators can 432 consider to provision a full IPv4 address to those users. If an 433 operator still want to provision restricted ports to specific users, 434 it may require to implement static user's configuration in the AFTR 435 to match the B4's IPv6 address to the NAT rules. Alternatively, the 436 B4 element may dynamically allocate the ports and the AFTR 437 authenticates the user's request using PCP [I-D.ietf-pcp-base]. 439 2.12. DS-Lite Tunnel Security 441 [RFC6333] Section 11 describes security issues associated to DS-Lite 442 mechanism. To restrict the service offered by AFTR only to 443 registered users, an operator can implement Outgoing Policy on the 444 AFTR's tunnel interface to accept only the IPv6 prefixes defined in 445 the policy. For static provisioning, the operator will need to know 446 in advance the IPv6 prefixes provisioned to the users for the 447 softwire in order to configure the policy. To simplify operation, 448 operators should configure the AFTRs in the same region with the same 449 IPv6 prefixes Outgoing Policy. The AFTRs will accept both regular 450 connections and failover connections from the B4 elements in the same 451 service region. 453 2.13. IPv6-only Network Considerations 455 In environments where the operator wants to deploy AFTR in the IPv6- 456 only network, the AFTR nodes may not have direct IPv4 connectivity. 457 In this scenario the operator extends the IPv6-only boundary to the 458 border of the network and only the border routers have IPv4 459 connectivity. For both scalability and performance purposes, AFTR is 460 located in the IPv6-only network closer to B4 elements. In this 461 scenario the AFTR has only IPv6 connectivity and must be able to send 462 and receive IPv4 packets. Enhancements to the DS-Lite AFTR are 463 required to achieve this. [I-D.boucadair-softwire-dslite-v6only] 464 describes such issues and enhancements to DS-Lite in IPv6-only 465 deployments. 467 3. B4 Deployment Considerations 469 In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs 470 the IPv6 address of the AFTR element. This IPv6 address can be 471 configured using a variety of methods, ranging from an out-of-band 472 mechanism, manual configuration, DHCPv6 option to RADIUS. If an 473 operator uses DHCPv6 to provision the B4, the B4 element must 474 implement the DHCPv6 option defined in [RFC6334]. If an operator 475 uses RADIUS to provision the B4, the B4 element must implement 476 [RFC6519]. 478 3.1. DNS Deployment Considerations 480 [RFC6333] recommends the B4 element should send DNS queries to an 481 external recursive resolver over IPv6. The B4 element should 482 implement proxy resolver that will proxy DNS query from IPv4 483 transport to the DNS server in the IPv6 network. [RFC6333] does not 484 describe the DNS proxy behavior. In deployment, the operator must 485 ensure that the DNS proxy implementation must follow [RFC5625]. This 486 is important especially for operators who have deployed or consider 487 to deploy DNSSEC [RFC4035]. 489 Some operators may want to give clients behind the B4's element an 490 IPv4 address of an external DNS recursive resolver. The B4 element 491 will treat the DNS packets as normal IP packets and forward over the 492 softwire. Note that there is no effective way to provision an IPv4 493 DNS address to the B4 over IPv6, operators who use this DNS 494 deployment model must be aware that it is undefined how to provision 495 an IPv4 DNS address over an IPv6 network, so it will introduce 496 additional complexity in B4 provisioning. Moreover, this will 497 increase load to AFTR by creating entries in the NAT table for DNS 498 sessions. Operators may deploy a local DNS caching resolver in AFTR 499 to reduce the load in the NAT table. Nonetheless, this DNS model is 500 not covered in [RFC6333] and is not recommended. 502 3.2. IPv4 Service Monitoring 504 3.2.1. B4 Remote Management 506 B4 is connected to IPv6 access network to offer IPv4 services. When 507 users experience IPv4 connectivity issue, operators must be able to 508 remotely access (e.g. TR-069) the B4 element to verify its B4's 509 configuration and status. Operators should access B4 elements using 510 native IPv6. Operators should not access B4 over the softwire. 512 3.2.2. IPv4 Connectivity Check 514 DS-Lite framework provides IPv4 services over IPv6 access network. 515 Operators and users must be able to check the IPv4 connectivity from 516 the B4 element to its AFTR using PING and IPv4 Traceroute. AFTR 517 should be configured with an IPv4 address to enable PING test and 518 Traceroute test. Operators should assign the same IPv4 address 519 (i.e., 192.0.0.2/32) to all AFTRs. IANA allocates 192.0.0.0/29 520 [RFC6333] Section 5.7 that can be used for this purpose. 522 4. Security Considerations 524 This document does not present any new security issues. [RFC6333] 525 discusses DS-Lite related security issues. 527 5. Acknowledgement 529 Thanks to Mr. Nejc Skoberne and Dr. Maoke Chen for their thorough 530 review and helpful comments. We also want to thank Mr. Hu Jie for 531 sharing his DS-Lite deployment experience to us. He gave us 532 recommendations what his company learned while testing DS-Lite in the 533 production network. 535 6. IANA Considerations 537 This memo includes no request to IANA. 539 7. References 541 7.1. Normative References 543 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 544 Stack Lite Broadband Deployments Following IPv4 545 Exhaustion", RFC 6333, August 2011. 547 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 548 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 549 RFC 6334, August 2011. 551 [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 552 Stack Lite", RFC 6519, February 2012. 554 7.2. Informative References 556 [I-D.boucadair-softwire-dslite-v6only] 557 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 558 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 559 Stack Lite in IPv6 Network", 560 draft-boucadair-softwire-dslite-v6only-01 (work in 561 progress), April 2011. 563 [I-D.ietf-intarea-nat-reveal-analysis] 564 Boucadair, M., Touch, J., Levis, P., and R. Penno, 565 "Analysis of Solution Candidates to Reveal a Host 566 Identifier (HOST_ID) in Shared Address Deployments", 567 draft-ietf-intarea-nat-reveal-analysis-04 (work in 568 progress), August 2012. 570 [I-D.ietf-pcp-base] 571 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 572 Selkirk, "Port Control Protocol (PCP)", 573 draft-ietf-pcp-base-29 (work in progress), November 2012. 575 [I-D.xu-behave-stateful-nat-standby] 576 Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy 577 Requirements and Framework for Stateful Network Address 578 Translators (NAT)", 579 draft-xu-behave-stateful-nat-standby-06 (work in 580 progress), October 2010. 582 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 583 IPv6 Specification", RFC 2473, December 1998. 585 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 586 and W. Weiss, "An Architecture for Differentiated 587 Services", RFC 2475, December 1998. 589 [RFC2983] Black, D., "Differentiated Services and Tunnels", 590 RFC 2983, October 2000. 592 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 593 Address Translator (Traditional NAT)", RFC 3022, 594 January 2001. 596 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 597 Rose, "Protocol Modifications for the DNS Security 598 Extensions", RFC 4035, March 2005. 600 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 601 (ICE): A Protocol for Network Address Translator (NAT) 602 Traversal for Offer/Answer Protocols", RFC 5245, 603 April 2010. 605 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 606 BCP 152, RFC 5625, August 2009. 608 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 609 RFC 5985, September 2010. 611 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 612 Roberts, "Issues with IP Address Sharing", RFC 6269, 613 June 2011. 615 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 616 Tschofenig, H., and H. Schulzrinne, "An Architecture for 617 Location and Location Privacy in Internet Applications", 618 BCP 160, RFC 6280, July 2011. 620 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 621 "Logging Recommendations for Internet-Facing Servers", 622 BCP 162, RFC 6302, June 2011. 624 Authors' Addresses 626 Yiu L. Lee 627 Comcast 628 One Comcast Center 629 Philadelphia, PA 19103 630 U.S.A. 632 Email: yiu_lee@cable.comcast.com 633 URI: http://www.comcast.com 635 Roberta Maglione 636 Telecom Italia 637 Via Reiss Romoli 274 638 Torino 10148 639 Italy 641 Email: roberta.maglione@telecomitalia.it 642 URI: 644 Carl Williams 645 MCSR Labs 646 U.S.A. 648 Email: carlw@mcsr-labs.org 650 Christian Jacquenet 651 France Telecom 652 Rennes 653 France 655 Email: christian.jacquenet@orange.com 657 Mohamed Boucadair 658 France Telecom 659 Rennes 660 France 662 Email: mohamed.boucadair@orange.com