idnits 2.17.1 draft-zhang-behave-nat64-load-balancing-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4673 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-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft X. Xu 4 Intended status: Informational Huawei Technologies Co.,Ltd 5 Expires: January 12, 2012 M. Boucadair 6 France Telecom 7 July 11, 2011 9 Considerations on NAT64 Load-Balancing 10 draft-zhang-behave-nat64-load-balancing-03 12 Abstract 14 This document investigates several load-balancing approaches for 15 NAT64 devices and analyzes the advantages and disadvantages of 16 various prefix selection policies. Both stateless and stateful NAT64 17 schemes are considered in this document. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 12, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Reminder on the Load Balancing Objectives . . . . . . . . . . 3 62 3.1. Inbound Load Balancing . . . . . . . . . . . . . . . . . . 4 63 3.2. Outbound Load Balancing . . . . . . . . . . . . . . . . . 5 64 4. Basic Load Balancing Considerations . . . . . . . . . . . . . 5 65 5. Stateless NAT64 . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Anycast-based Mode . . . . . . . . . . . . . . . . . . . . 6 67 5.2. DHCPv6-based Mode . . . . . . . . . . . . . . . . . . . . 7 68 5.3. NAT64 Farm . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Anycast-based Mode . . . . . . . . . . . . . . . . . . . . 8 71 6.2. Prefix64 Selection Policy . . . . . . . . . . . . . . . . 8 72 6.2.1. Source-Based Prefix Selection Policy . . . . . . . . . 8 73 6.2.2. Destination-Based Prefix Selection Policy . . . . . . 9 74 6.2.3. Round-Robin Prefix Selection Policy . . . . . . . . . 10 75 6.2.4. Dynamic Prefix Selection Policy . . . . . . . . . . . 10 76 6.3. Options for Implementing Load-balancers . . . . . . . . . 11 77 6.3.1. DNS64 Servers . . . . . . . . . . . . . . . . . . . . 11 78 6.3.2. Prefix64 Assigners . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 NAT64 devices [I-D.ietf-behave-v6v4-xlate-stateful] are facilities 90 deployed on the boundaries between IPv6 and IPv4 networks to 91 facilitate the communication between IPv6-only clients and IPv4 92 servers. 94 This document proposes several load-balancing approaches for NAT64 95 devices, which can be utilized in the delivery of highly available 96 services, and compares the advantages and disadvantages of various 97 prefix selection policies. 99 The issues with failover and redundancy are outside the scope of this 100 document. An in depth analysis of those issues is elaborated in 101 [I-D.xu-behave-stateful-nat-standby]. 103 2. Terminology 105 This document makes use of the terms defined in [I-D.ietf-behave- 106 v6v4-xlate-stateful], [I-D.ietf-behave-dns64] and [RFC6052]. Below 107 are provided the terms specific to this document: 109 o Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses 110 representing IPv4 hosts in the IPv6 realm. See [RFC6052] for more 111 details on how IPv4-embedded IPv6 addresses are built. 113 o NAT64-enabled device (or NAT64 device for short): is a device 114 which embeds a NAT64 function as defined in [I-D.ietf-behave-v6v4- 115 xlate-stateful]. 117 o A load-balancer is a facility which can select a NAT64 device from 118 a set of deployed devices for a given IPv6-only client according 119 to the pre-specified policy. Typically, a load-balancer 120 provisions a client with an IPv6 address of the IPv4-only server 121 that the client is going to access. Prefix64 is elaborately 122 selected by the load-balancer so that the corresponding NAT64 123 device can intercept the packets between the above communicating 124 parties and correctly process them. 126 3. Reminder on the Load Balancing Objectives 128 Load balancing is a technique used by network operators (including 129 service providers, enterprise networks, etc.) to distribute the load 130 among several ingress/egress points, several paths, several 131 topologies, etc. 133 In the context of IPv4-IPv6 interconnection, load balancing is mainly 134 motivated by the needs listed below: 136 o to optimize the resources usage of deployed NAT64 devices (e.g., 137 several ingress/egress NAT64 devices); 139 o to avoid congesting a single NAT64 device while other free 140 resources are still available; 142 o to optimize IPv6-IPv4 interconnection costs especially when 143 several NAT64 providers are involved. 145 Techniques to balance the load among a set of NAT64 devices can be 146 achieved on a load-balancer managing a farm of NAT64 devices, on a 147 single NAT64 device to select the appropriate outbound interface, or 148 it can be implicitly achieved owing to dedicated tweaking operations 149 (e.g., use of anycast-based service, use of distinct Prefix64, etc.). 150 Note that considerations to balance the traffic between several 151 outbound interfaces of a NAT64 device are out of scope of this 152 document. 154 Various types of load balancing can be considered as defined in the 155 following sub-sections. 157 3.1. Inbound Load Balancing 159 Inbound load balancing means that incoming traffic (i.e., the traffic 160 received from an IPv4-only host) is distributed among a set of NAT64 161 devices located at the boundary of the IPv4 realm and the IPv6 one. 163 In a stateful NAT64 case, inbound load balancing cannot be explicitly 164 configured because IPv4-only clients can not initiate sessions to an 165 IPv6-only server (except for IPv6-only hosts which pre-installed 166 static entries in the NAT64 using PCP [I-D.ietf-pcp-base] for 167 instance). 169 In a stateless NAT64 case, inbound load balancing can be achieved by 170 configuring distinct IPv4 address pools on each stateless NAT64 171 device (or these pools are to be configured with distinct routing 172 metrics in each NAT64 device). This practice may lead to asymmetric 173 paths (i.e., distinct NAT64 devices will handle the outgoing and the 174 inbound packets) if the same NSP (Network Specific Prefix, [RFC6052]) 175 is provisioned on those NAT64 devices. This can be seen as an issue 176 for some operators because the legal stored data and activity logs 177 can be increased. If downstream and upstream paths have similar 178 characteristics (e.g., one-way delay, one-way delay variation, 179 throughput), the path asymmetry is not an issue from a service 180 perspective. 182 Note: As an alternative to address this problem, a load balancer 183 needs to be deployed on each side of the NAT64 devices. The 184 balancers need to know the policies of each other so as to work in a 185 cooperative way. Refer to Section 6.2 for more discussion. 187 3.2. Outbound Load Balancing 189 Outbound load balancing means the effort of distributing outgoing 190 traffic (i.e., the traffic issued by IPv6-only hosts) among a set of 191 NAT64 devices. 193 Only this flavor of load balancing is elaborated in the remainder of 194 this document. 196 4. Basic Load Balancing Considerations 198 In practice, it is important to guarantee the outgoing traffic and 199 the associated incoming traffic is stuck to a same stateful NAT64 200 device, so that the NAT64 device can get essential knowledge to 201 correctly process the incoming packets. That is, if a stateful NAT64 202 device processes a request from an IPv6 client to an IPv4 server, it 203 MUST be able to intercept and process the correspondent reply from 204 the server. To achieve this, distinct external IPv4 addresses SHOULD 205 be configured on each stateful NAT64 device. Otherwise, if the same 206 IPv4 address pool is provisioned on two distinct NAT64 devices (e.g., 207 NAT64-A and NAT64-B) and since the routing paths may not be 208 symmetric, outbound packets may be intercepted by NAT64-A while 209 inbound packets may be received by NAT64-B. NAT64-B will reject the 210 packets it received because no state to process these packets was 211 instantiated beforehand, and thus the communication will fail. 213 The load balancing SHOULD NOT be solely done based on the traffic 214 load distribution but SHOULD persevere the assignment of the same 215 external IPv4 address for all active sessions initiated by an IPv6- 216 only host. The criteria for distributing customers among a set of 217 NAT64 devices may be implemented during the IPv6 configuration phase 218 of a IPv6-only host or during the processing of actual traffic issued 219 by that host. 221 In the circumstances where the static mapping entries of an IPv6-only 222 client are pre-installed in a given stateful NAT64 device, the 223 enforced load-balancing technique SHOULD "redirect" the traffic from 224 the client to the NAT64-device where its static mappings are pre- 225 installed. 227 Note: Some dynamic protocols such as PCP [I-D.ietf-pcp-base] may 228 include manes to detect the unavailability of a NAT64 and to re- 229 install the mappings in the new discovered NAT64. But, for the 230 manually configured mappings, the issue is still there. 232 From the operator's perspective, a load balancing solution SHOULD be 233 deterministic, that is, that the actual traffic distribution should 234 be strictly compliant with what is expected by the system manager. 235 Furthermore, the operations of distributing the load among multiple 236 NAT64 devices SHOULD be covered from end-users. This means that end- 237 users should not be aware of the presence of multiple NAT64 devices 238 in the core network and the selection of the appropriate NAT64 device 239 should not assume any intervention by the customer/host. 241 When implementing load balancing, it should not lead to (severe) QoS 242 degradation between potential paths. Note that the perceived quality 243 may not only depend on the load balancing technique to distribute the 244 traffic among available path/nodes but it is closely related to the 245 underlying topology (i.e., location of the NAT64 devices, routing 246 metrics configuration, etc.). 248 An efficient load balancing system SHOULD NOT redirect the traffic to 249 a congested NAT64 device while other NAT64 resources are available. 250 Load indicators (i.e., the data reflecting the load imposed on NAT64 251 devices) may be disseminated to drive the process of selecting a 252 NAT64 device to handle an ongoing IPv6 packet. These indicators may 253 be based on (almost) real-time measurement tools or based on a 254 traffic logic configured on the load-balancer (e.g., a NAT64 device 255 can handle N IPv6-only hosts). 257 5. Stateless NAT64 259 According to [RFC6052], IPv4-Translated and IPv4-Converted IPv6 260 addresses SHOULD use the same Network Specific Prefix (NSP). To 261 distribute the traffic among a set of stateless NAT64 devices, the 262 alternatives described hereafter can be envisaged. For the anycast- 263 based mode the same Prefix64 is used while for the remaining options, 264 specific Prefix64s are used. 266 5.1. Anycast-based Mode 268 The same IPv6 NSP is provisioned to all stateless NAT64 devices; IPv6 269 hosts are distributed natively among several stateless NAT64 devices. 270 This means that the closest (from a routing perspective) stateless 271 NAT64 device will be used to process IPv6 (resp. IPv4) packets 272 destined to an IPv4 (resp. IPv6) destination. 274 The efficiency of this mode largely depends on the underlying 275 topology (e.g., location of NAT64 devices) and routing engineering 276 policies. Moreover, a stateless NAT64 device may be overloaded if 277 the routing is not appropriately tuned and/or if the NAT64 devices 278 are not appropriately dimensioned. 280 The introduction or the removal of NAT64 device(s) can be achieved 281 without modifying the configuration of DHCPv6 servers. During 282 failure events of a NAT64 system, other NAT64 devices can handle the 283 traffic without any intervention. 285 5.2. DHCPv6-based Mode 287 To implement this mode, each stateless NAT64 device is configured 288 with a dedicated NSP. During the IPv6 prefix assignment phase, 289 requesting IPv6 hosts are provided with IPv4-Translated IPv6 prefix 290 using the NSP of the NAT64 device that will be used to handle traffic 291 issued from those hosts and destined to an IPv4 host. 293 If DHCPv6 is used for the provisioning of IPv6 prefixes, DHCPv6 294 servers SHOULD be provided with the number of customers to be 295 serviced per dedicated NSP (i.e., an NSP prefix identifies a 296 stateless NAT64 device). Dynamic load information (based on real 297 time monitoring) MAY be provided to the DHCPv6 to drive the process 298 of IPv6 prefix assignment and for better utilization of available 299 NAT64 resources. Furthermore, and for routing optimization purposes 300 and for service stability purpose (e.g., use the same NAT64 device 301 hosting PCP-instructed port forwarding entries), other topological 302 information SHOULD be used to tag the customers that should be 303 serviced by each NAT64 device. 305 5.3. NAT64 Farm 307 An additional scheme would be the deployment of a farm of NAT64 308 devices with a load-balancer which is responsible for redirecting the 309 traffic to the appropriate NAT64 instance. Unlike stateful NAT64, 310 both IPv4 and IPv6 flows can be load balanced. 312 In this scenario, the same NSP SHOULD be used for all NAT64 devices 313 belonging to the same farm. 315 Techniques to distribute the load among the NAT64 devices of the farm 316 are similar to load-balancing techniques among several outbound 317 interfaces of the same NAT64 system. 319 6. Stateful NAT64 321 Tow variant of the load balancing techniques are elaborated 322 hereafter. Unlike the first mode, anycast-based, the second category 323 requires Prefix64 selection to achieve load balancing. More details 324 are provided below. 326 6.1. Anycast-based Mode 328 This mode assumes that the same IPv6 prefix (i.e., NSP or WKP, see 329 [RFC6052]) is provisioned to all deployed stateful NAT64 devices. 330 DNS64 function is provisioned with that prefix used for synthesizing 331 AAAA records. 333 As stated in Section 4, distinct IPv4 address pools are configured to 334 each NAT64 device. This ensures path symmetry; which means that the 335 same NAT64 device will be used for handling both outbound and inbound 336 packets exchanged in a same stateful conversation between two hosts. 338 The distribution of the traffic among deployed NAT64 devices is 339 natively achieved relying on the underlying routing configuration. 340 Off-line traffic engineering tools can be used to appropriately tweak 341 the routing metrics so as to allow for acceptable traffic 342 distribution. 344 The same NAT64 device SHOULD be used to handle all the packets issued 345 by a given IPv6 host so that the same external IPv4 address is used 346 to represent that host in the IPv4 realm. This means that 347 oscillation phenomena induced by underlying routing MUST be avoided. 348 By oscillation it is meant that the traffic customer is balanced 349 between two NAT64 devices. The routing oscillation can be avoided 350 owing to (off-line/on-line) traffic engineering techniques to select 351 the appropriate location of the NAT64 devices in the network, the 352 setting of underlying routing weights, establishment of explicit MPLS 353 LSPs, etc. 355 6.2. Prefix64 Selection Policy 357 It is RECOMMENDED that the functionality of load balancers should be 358 integrated into dedicated servers. Therefore, load-balancing can be 359 transparent for IPv6-only hosts. The design options of load 360 balancers are discussed in Section 6.3. 362 The following sub-sections elaborate on various modes for the prefix 363 selection. 365 6.2.1. Source-Based Prefix Selection Policy 367 A source-based prefix selection policy allows a load-balancer to 368 select Prefix64s according to the IPv6 addresses of its IPv6-only 369 clients. For instance, when using a source-based prefix selection 370 policy, the load-balancer in the above example can allocate an IPv6 371 address with Prefix64-A for the IPv4-only server if the IPv6 address 372 of the client is odd, and Prefix64-B otherwise. 374 6.2.1.1. Pros 376 It is simple and has enough entropy to ensure reasonable load 377 balancing across different NAT64 devices. 2. 379 The users are consistently assigned to the same NAT64 device for 380 every outbound session. This is important because some applications 381 identify a unique user across multiple transactions using the source 382 IP address; examples include FTP and SSL VPNs. In addition, it is 383 easier for a network management system (NMS) to monitor and manage 384 the activities of a user. For instance, a NMS can collect the 385 information about number of the concurrent sessions initiated by a 386 user from a single NAT64 device. However, when using other policies, 387 a user is not stuck to a NAT64 device, and thus NMS may have to 388 collect such information from multiple NAT64 devices. 390 6.2.1.2. Cons 392 The efficiency of this procedure depends on the selection criteria 393 and may not be deterministic in some cases where the traffic may be 394 redirected to a congested NAT64 device. 396 6.2.2. Destination-Based Prefix Selection Policy 398 A destination-based prefix selection policy requires a load-balancer 399 to choose Prefix64s according to the IP addresses of the IPv4 400 targets. For instance, when using a destination-based prefix 401 selection policy, the load-balancer in the above example can allocate 402 an IPv6 address with Prefix64-A for the IPv4 server if the IPv4 403 address of the server is odd, and prefix64-B otherwise. In practice, 404 this type of policy can have lots of variations. For instance, when 405 a DNS server is utilized as a load balancer, the server can select a 406 prefix64 according to the hash value of the FQDN (Fully Qualified 407 Domain Name) of the target server. 409 6.2.2.1. Pros 411 It is simple to implement; 413 6.2.2.2. Cons 415 A user accessing multiple IPv4 servers may be represented by multiple 416 public IPv4 addresses since its traffic may be processed by different 417 NAT64 systems. This will cause authentication problems in the 418 applications (e.g., FTP and SSL VPNs) which take advantage of the 419 source IP addresses to identify users across different sessions. 2. 421 A user can not be redirected to the NAT64 device where it has 422 instructed its port forwarding entries; 3. 424 Since there are more users than the servers providing contents, there 425 is not enough entropy to ensure good load balancing. The NAT64 426 device that services a popular web-site will have to undertake much 427 traffic. It is possible to define some strategies to make major 428 sites evenly assigned to different NAT64s, e.g.- Google to NAT64-A, 429 Facebook to NAT64-B, However, this solution can be onerous and 430 requires heavy human involvement. 432 6.2.3. Round-Robin Prefix Selection Policy 434 A round-robin prefix selection policy allows a load-balancer to use 435 various Prefix64s circularly in different requesting sessions. For 436 instance, in the above example, the load-balancer can choose 437 Prefix64-A in the first requesting session, choose Prefix64-B in the 438 second, choose Prefix64-A in the third, choose Prefix64-B in the 439 fourth, and so on. 441 6.2.3.1. Pros 443 Ensures reasonable distribution among a set of NAT64 devices. 445 6.2.3.2. Cons 447 A given IPv6-only hosts may be redirected to distinct NAT64 devices. 448 Therefore, distinct IPv4 address may be used to represent the IPv6- 449 only host in the IPv4 realm; 451 A user can not be redirected to the NAT64 device where it has 452 instructed its port forwarding entries; 454 Requires a load balancer (e.g., a DNS64 or a DHCP server) to keep 455 track of the assignments. 457 6.2.4. Dynamic Prefix Selection Policy 459 Although the capability of NAT64 devices can be considered as a 460 factor in the designing of the above three types of policies, they 461 are still static and not able to be adjusted according the load 462 changes of NAT64 devices in a timely fashion. If we intend to enable 463 a load-balancer to dynamically modify its policies according to 464 NAT64s' real-time load changes, a dynamic prefix selection policy is 465 necessary. For instance, a DNS64 system or DHCPv6 can use SNMP to 466 collect the information of the overheads (e.g., CPU utilizing rates, 467 free memory amounts, concurrent session numbers, and session numbers 468 per second) imposed on different NAT64-based devices. Based on such 469 information, the load-balancer can distribute the loads on different 470 NAT64 devices in a more reasonable way. 472 6.2.4.1. Pros 474 This type of policy can effectively avoid the unbalanced distribution 475 of overheads on different NAT64 devices. 477 6.2.4.2. Cons 479 Such a policy may introduce additional communication and management 480 complexities to a NAT64 device. The complexity depends on the means 481 used to disseminate the NAT64 load. 483 6.3. Options for Implementing Load-balancers 485 In practice, the functionality of a load-balancer can be performed 486 by, e.g.- a DNS64 server, a DNS server, a DHCP server, an edge 487 router, or even an IPv6 host itself. 489 6.3.1. DNS64 Servers 491 When collaborating with NAT64 devices, a DNS64 server can be 492 solicited by an IPv6-only client to initiate communications to an 493 IPv4-only server identified by a FQDN. 495 Let us assume there is an IPv6-only client connected to an IPv6 496 network which attempts to communicate to an IPv4-only server. For 497 the purpose of load balancing, the DNS64 server needs to select a 498 Prefix64 based on one of the prefix selection policies defined in 499 Section 6.2 and use it when synthesizing AAAA RRs. Using the 500 synthesized IPv6 address, the IPv6-only client will take advantage of 501 the NAT64 associated with the Prefix64 to communicate with the IPv4- 502 only server. 504 When DNS64 is used as a means to load balance the hosts among a group 505 of NAT, DNS64 SHOULD be able to assign the same NAT64 to the same 506 hosts. Means to identify the host SHOULD be supported. This is not 507 natively supported by DNS servers. 509 A drawback of this mode is that for traffic which does not require a 510 DNS resolution, the packets may flow using a distinct NAT device, and 511 therefore use a distinct external IP address. 513 6.3.2. Prefix64 Assigners 515 [I-D.korhonen-behave-nat64-learn-analysis] analyzes various solutions 516 for a host in an IPv6-only network to obtain the Prefix64 of a NAT64 517 device. With the Prefix64, the hosts can synthesize an appropriate 518 IPv6 address which can route packets to the translator. In the 519 designing of load balancers for NAT64 devices, these approaches are 520 worthwhile to consider. 522 6.3.2.1. DNS64 Servers 524 In [I-D.korhonen-behave-nat64-learn-analysis], a NAPTR RR to 525 represent NAT64's Prefix64 is analyzed as part of the candidate 526 solutions. When using DNS servers to act as load balancers for NAT64 527 devices, multiple NAPTR RRs need to be added the zone file. Every 528 NAPT RR consists of a Prefix64. Upon receiving a NAPTR query, the 529 DNS server replies the requester with a NAPTR RR according to a pre- 530 specified selection policy. Note that the destination-based prefix 531 selection policy is not applicable in this case because the DNS 532 server may lack the knowledge of the IP address of the queried IPv4 533 host. 535 6.3.2.2. DHCPv6 Servers 537 It is mentioned in [I-D.korhonen-behave-nat64-learn-analysis] that a 538 DHCPv6 server can be used to allocate Prefix64s for hosts, and so a 539 DHCP server has a potential to act as a load balancer for NAT64 540 devices. Similar with the solution proposed in Section 6.3.2.1, it 541 is difficult for a DHCP server to identify the IP addresses of the 542 IPv4 hosts which its clients intend to communicate with. Therefore, 543 only the source-based policy, the round-robin policy, or the dynamic 544 policy can be used in this approach. 546 Also, a DHCPv6 server can be adopted to allocate different DNS64 547 servers for its users in various standard DHCPv6 host configuration 548 processes according to certain selection polices. Unlike the DNS64 549 servers discussed in Section 6.3.1, in this case a DNS64 server needs 550 to only synthesize AAAA records using a single Prefix64. 552 The load of NAT devices may be provided to DHCP servers to assist the 553 selection of the DNS64 to be used for new connecting hosts. 555 6.3.2.3. Default Gateways 557 [I-D.korhonen-behave-nat64-learn-analysis] also discusses the 558 possibility of using Router Advertisement (RA) messages to transfer 559 Prefix64s for IPv6 users. If the edge router is attached to only one 560 multicast link, no prefix selection policy defined in Section 6.2 can 561 be used. If the edge router is attached to multiple multicast links, 562 the source-based policy, the round-robin policy or the dynamic policy 563 can be used. Because at this phase it is difficult for an edge 564 router to identify the IP addresses of the IPv4 hosts which the IPv6 565 hosts will communicate with, the destination-based prefix selection 566 policy is unfeasible. 568 6.3.2.4. IPv6 Clients 570 It is possible for an IPv6 host to learn multiple Prefix64s through 571 the approaches defined in [I-D.korhonen-behave-nat64-learn-analysis] 572 and then select one based on a certain prefix selection policy. Such 573 a policy can be the destination-based policy, the source-based policy 574 (only one prefix64 is used), the round-robin policy or the dynamic 575 policy. 577 This solution is not deterministic and can lead to congesting a given 578 NAT64 device. 580 7. IANA Considerations 582 This document makes no request of IANA. 584 Note to RFC Editor: this section may be removed on publication as an 585 RFC. 587 8. Security Considerations 589 As mentioned previously, all the traffic between an IPv6 host and an 590 IPv4 host should be intercepted and processed by a same NAT64 device. 591 However, when using certain policies (e.g., the destination-based 592 prefix selection policy and the Round-Robin prefix selection policy), 593 this requirement cannot be fulfilled. The traffic of a user will be 594 distributed to different NAT64 devices. Under such a circumstance, 595 it may be difficult for network management systems to collect 596 information from different NAT64 devices in order to monitor users' 597 behavior in a real in time fashion. In addition, it can be difficult 598 for intrusion detection/prevision systems to combine the operations 599 of a user so as to reason whether she is trying to perform a multi- 600 step attack. 602 Another security concern is load balancers. Because load balancers 603 play an important role in distributing traffic to different NAT64 604 devices, the communication between users and load balancers should be 605 secured. Otherwise, attackers may disturb load balancing and carry 606 out DDoS attacks by modifying the packets sent from load balancers. 608 9. Contributors 610 The following individuals have contributed to this document: 611 Xuewei Wang 612 Huawei Technologies Co.,Ltd 613 KuiKe Building, No.9 Xinxi Rd., 614 Hai-Dian District, Beijing 100085 615 P.R. China 617 Email: wangxuewei@huawei.com 619 Yan Wang 620 CNNIC 621 No.4 South 4th Street, 622 Beijing, Zhongguancun 100190 623 P. R. China 625 Email: wangyan-lab@cnnic.cn 627 Cameron Byrne 628 T-Mobile USA 629 3617 131st Ave SE 630 Bellevue, WA 98006 631 US 632 Email: cameron.byrne@t-mobile.com 634 Dong Zhang 635 Huawei Symantec 636 KuiKe Building, No.9 Xinxi Rd., 637 Beijing, Hai-Dian District 100085 638 P. R. China 640 Email: zhangdong_rh@huaweisymantec.com 642 Zhenqiang Li 643 China Mobile 644 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xicheng District 645 Beijing 100053 646 P.R. China 648 Email: lizhenqiang@chinamobile.com 650 10. References 651 10.1. Normative References 653 [I-D.ietf-behave-dns64] 654 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 655 "DNS64: DNS extensions for Network Address Translation 656 from IPv6 Clients to IPv4 Servers", 657 draft-ietf-behave-dns64-11 (work in progress), 658 October 2010. 660 [I-D.ietf-behave-v6v4-xlate-stateful] 661 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 662 NAT64: Network Address and Protocol Translation from IPv6 663 Clients to IPv4 Servers", 664 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 665 progress), July 2010. 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 671 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 672 October 2010. 674 10.2. Informative References 676 [I-D.ietf-pcp-base] 677 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 678 Selkirk, "Port Control Protocol (PCP)", 679 draft-ietf-pcp-base-13 (work in progress), July 2011. 681 [I-D.korhonen-behave-nat64-learn-analysis] 682 Korhonen, J. and T. Savolainen, "Analysis of solution 683 proposals for hosts to learn NAT64 prefix", 684 draft-korhonen-behave-nat64-learn-analysis-02 (work in 685 progress), February 2011. 687 [I-D.xu-behave-stateful-nat-standby] 688 Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy 689 Requirements and Framework for Stateful Network Address 690 Translators (NAT)", 691 draft-xu-behave-stateful-nat-standby-06 (work in 692 progress), October 2010. 694 Authors' Addresses 696 Dacheng Zhang 697 Huawei Technologies Co.,Ltd 698 KuiKe Building, No.9 Xinxi Rd., 699 Hai-Dian District, Beijing 100085 700 P.R. China 702 Email: zhangdacheng@huawei.com 704 Xiaohu Xu 705 Huawei Technologies Co.,Ltd 706 KuiKe Building, No.9 Xinxi Rd., 707 Hai-Dian District, Beijing 100085 708 P.R. China 710 Email: xuxh@huawei.com 712 Mohamed Boucadair 713 France Telecom 714 Rennes, 715 France 717 Email: mohamed.boucadair@orange-ftgroup.com