idnits 2.17.1 draft-xu-behave-stateful-nat-standby-06.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 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2010) is 4930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Huawei Technologies Co.,Ltd 4 Intended status: Informational M. Boucadair 5 Expires: April 23, 2011 France Telecom 6 Y. Lee 7 Comcast 8 G. Chen 9 China Mobile 10 October 20, 2010 12 Redundancy Requirements and Framework for Stateful Network Address 13 Translators (NAT) 14 draft-xu-behave-stateful-nat-standby-06 16 Abstract 18 This document defines a set of requirements and a framework for 19 ensuring redundancy for stateful Network Address Translators (NAT), 20 including NAT44, NAT64 and NAT46. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 23, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . . 3 64 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 5 67 4. Dynamic and Static States . . . . . . . . . . . . . . . . . . 6 68 5. Overview of Redundancy Mechanisms . . . . . . . . . . . . . . 6 69 6. Cold Standby Mode . . . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Internal Realm . . . . . . . . . . . . . . . . . . . . . . 8 71 6.2. External Realm . . . . . . . . . . . . . . . . . . . . . . 8 72 6.3. NAT Reachability Announcement . . . . . . . . . . . . . . 9 73 7. Hot Standby Mode . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Internal Realm . . . . . . . . . . . . . . . . . . . . . . 10 75 7.2. External Realm . . . . . . . . . . . . . . . . . . . . . . 10 76 7.3. NAT Reachability Announcement . . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Appendix A. State Synchronization Protocol Considerations . . . . 12 84 Appendix B. Election Protocol Considerations . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Network Address Translation (NAT) has been used as an efficient way 90 to share the same IPv4 address among several hosts. Recently, due to 91 IPv4 address shortage, several proposals have been elaborated to rely 92 on Carrier Grade NAT (CGN, a.k.a.- LSN for Large Scale NAT) (e.g., 93 [I-D.shirasaki-nat444-isp-shared-addr], 94 [I-D.ietf-softwire-dual-stack-lite] and 95 [I-D.ietf-behave-v6v4-xlate-stateful]). In such models, CGN function 96 (which may be embedded in a router or be deployed in standalone 97 devices) is deployed within large-scale networks, such as ISP 98 networks or enterprise ones, where a large number of customers are 99 located. These customers within a network which is served by a 100 single CGN device may experience service degradation due to the 101 presence of the single point of failure or loss or state information. 102 Therefore, redundancy capabilities of the CGN devices are strongly 103 desired in order to deliver highly available services to customers. 104 Failure detection and repair time must be therefore shortened. 106 This document describes a framework of redundancy for stateful NAT 107 including: NAT44 including DS-Lite, NAT64 and NAT46. 109 The main purpose of this document is to analyze means to ensure high 110 availability in environments where carrier grade NAT44, NAT64 and 111 NAT46 are deployed. Some engineering recommendations are provided 112 for the selection of the IPv6 prefix to build IPv4-Embedded IPv6 113 addresses [I-D.ietf-behave-address-format] and the routing 114 configuration. 116 Except dealing with the exceptional failures (e.g., power outage, OS 117 crash-down or link failure, etc.), the redundancy mechanism described 118 in this document can also be used for planned maintenance operations 119 (i.e., graceful shutdown of the Primary NAT due to maintenance 120 needs). 122 Unless otherwise mentioned, NAT and CGN terms throughout this 123 document, pertain to stateful NAT and stateful CGN. Stateless NAT is 124 out of the scope of this document. 126 2. Terminology and Acronyms 128 2.1. Acronyms 129 CGN Carrier Grade NAT 130 LSN Large Scale NAT 131 DS-Lite Dual Stack Lite 132 AFTR Address Family Transition Router 133 NAT Network Address Translation 134 ISP Internet Service Provider 136 2.2. Terminology 138 This document makes use of the terms defined in [RFC2663]. Below are 139 provided terms specific to this document: 141 o CGN (Carrier Grade NAT) or LSN (Large Scale NAT): a NAT device 142 placed within a large-scale network (e.g., ISP network, enterprise 143 network, or campus network). CGN may be placed at the boundary 144 between the large-scale private network and the public Internet, 145 between a private network and a large-scale public network or 146 between two heterogeneous IP realms (i.e., IPv4 and IPv6). 148 o CGN internal address realm (internal realm for short): a realm 149 internal to the CGN. 151 For NAT44, the internal realm refers to the private networks. 153 For NAT64, the internal realm means IPv6 network or IPv6 154 Internet. 156 For NAT46, the internal realm refers to IPv4 network or IPv4 157 Internet. 159 For DS-Lite, the internal address realm is assumed to be 160 private IPv4 addresses even if the transport mode used to 161 convey exchanged traffic is IPv6. A DS-Lite CGN device 162 (a.k.a., Address Family Transition Router) is a special NAT44 163 function which uses the IPv6 address as a means to de-multiplex 164 users sharing the same IPv4 address 165 [I-D.ietf-softwire-dual-stack-lite]. 167 o The hosts located in the internal realm are called internal hosts, 168 and the addresses used in the internal realm are called internal 169 addresses. 171 o CGN external address realm (external realm for short): a realm 172 external to the CGN. 174 For NAT44, the external realm refers to the IPv4 Internet. 176 For NAT64, the external realm means the IPv4 Internet or IPv4 177 network. 179 For NAT46, the external realm refers to the IPv6 Internet or 180 IPv6 network. 182 o The hosts located in the external realm are called external hosts, 183 and the addresses used in the external realm are called external 184 addresses. 186 o Internal address pool: an address pool used for assigning internal 187 addresses to represent the external hosts in the internal realm. 188 This address pool is specific to NAT46 and NAT64. 190 For NAT46, the CGN will allocate one internal address (which is 191 an IPv4 address) from the pool to an external IPv6 host and map 192 the external IPv6 host's IPv6 address to this IPv4 address. 194 For NAT64, the CGN internal address pool is the Prefix64 195 [I-D.ietf-behave-address-format]. Prefix64 is used for 196 synthesizing internal IPv6 addresses to represent external IPv4 197 hosts in the internal realm. 199 o External address pool: an address pool used by the CGN for 200 assigning external addresses to the internal hosts. 202 For NAT44 and NAT64, the external address pool contains a set 203 of public IPv4 addresses. 205 For NAT46, the external IPv6 address pool is the Prefix64. 206 Prefix64 is used by the CGN for synthesizing the external IPv6 207 addresses to represent internal IPv4 hosts in the external 208 realm. 210 o CPE (Customer Premises Equipment): a device which is used to 211 interconnect the customer premise with the service provider's 212 network. 214 3. Reference Architecture 216 In a typical operational scenario, as illustrated in Figure 1, two 217 NAT devices are deployed for redundancy purposes. This is the 218 reference architecture for the mechanisms we describe in this memo. 219 Note that these mechanisms are also suitable in scenarios where more 220 than two NAT devices are used. 222 +-------------------------+ +-----------------------+ 223 | | | | 224 | +-+-----+-+ | 225 | | NAT-A | | 226 +----+-------------+ +-+-----+-+ +-------------+ | 227 | Internal Host | | | |External Host| | 228 +----+-------------+ | | +-------------+ | 229 | +-+-----+-+ | 230 | | NAT-B | | 231 | Internal realm +-+-----+-+ External realm | 232 | | | | 233 +-------------------------+ +-----------------------+ 235 Figure 1: General Scenario of Dual NAT Routers 237 The redundancy mechanisms for NAT44, NAT46 and NAT64 are almost 238 identical. In all cases, the NAT device or the immediate router of 239 the NAT device announces the reachability of the NAT device to the 240 external realm. The slight difference is the NAT reachability 241 information. For example, NAT64 announces an IPv6 route for the 242 Prefix64; NAT44 announces an IPv4 default route; DS-Lite AFTR 243 announces an IPv6 route pointing to itself; and NAT46 announces a 244 route for its internal address pool. This difference does not affect 245 the general redundancy mechanisms, so the mechanisms described in 246 this memo can be applied to NAT44, NAT64 and NAT46 devices. 248 4. Dynamic and Static States 250 The NAT states mentioned in this document only mean those NAT states 251 which are created dynamically by outgoing packets, rather than those 252 static NAT states which are configured manually or with automatic 253 means such as UPnP or PCP. For those static NAT states (a.k.a., port 254 forwarding entries), they are essentially part of the configuration 255 data. 257 Port forwarding entries SHOULD be stored in permanent storage 258 whatever the deployed redundancy mode. 260 5. Overview of Redundancy Mechanisms 262 The fundamental principle of NAT redundancy is to make two or more 263 NAT devices function as a redundancy group, and select one as the 264 Primary NAT and the other(s) as the Backup NAT through a dedicated 265 election procedure or manual configuration. 267 In the nominal regime, traffic exchanged between one host in the 268 internal realm and another host in the external realm is handled by 269 the Primary NAT. Once the Primary NAT is out of service, the Backup 270 NAT with the highest priority (if several Backup NAT devices are 271 deployed) takes over and provides the NAT services to the internal 272 hosts. This Backup NAT is then identified as new Primary NAT. Once 273 the former Primary NAT became operational, it could either preempt 274 the role of Primary NAT or stay as a candidate in the redundancy 275 group. This is part of administrative policies and out of scope of 276 this memo. 278 In order to implement the aforementioned procedure, means to detect 279 and to notify the failure of the Primary NAT to the redundancy group 280 SHOULD be activated. 282 To ensure a coherent behavior when NAT device fails, this document 283 assumes that both Primary and Backup NAT devices are managed by the 284 same administrative domain. Thus, consistent configuration policies 285 SHOULD be enforced in all devices. Note that the election process 286 MUST be deterministic and does not lead to ambiguous situation where 287 two or more NAT devices become Primary NAT. Moreover, the failover 288 SHOULD be quick to ensure service continuity and keep end-users from 289 perceiving service unavailability. 291 Three redundancy modes are described hereafter: the cold standby, the 292 hot standby and the partial hot standby modes: 294 1. The cold standby mode is simple. The NAT states are not 295 replicated from the Primary NAT to the Backup NAT. When the 296 Primary NAT fails, all the existing established sessions will be 297 flushed out. The internal hosts are required to re-establish 298 sessions to the external hosts; 300 2. The hot standby mode keeps established sessions while failover 301 happens. NAT states are replicated from the Primary NAT to the 302 Backup NAT. When the Primary NAT fails, the Backup NAT will take 303 over all the existing established sessions. The internal hosts 304 are not required to re-establish sessions to the external hosts. 306 3. The partial hot standby mode is a flavor of the hot standby mode 307 described above. It is used to avoid replicating NAT states of 308 trivial sessions (e.g., short lifetime sessions) while achieving 309 hot standby for significant sessions (e.g., critical protocols or 310 applications, long lifetime sessions etc.). Criteria for 311 sessions to be replicated on backup NATs SHOULD be explicitly 312 configured on the NAT devices of a redundancy group. 314 The following sections provide more information about the cold 315 standby and the hot standby modes. 317 6. Cold Standby Mode 319 6.1. Internal Realm 321 The internal addresses used to represent the external hosts in the 322 internal realm SHOULD be retained after the NAT failover. The 323 following assesses how this requirement is met in each NAT flavor: 325 o For NAT44 and DS-Lite, the external hosts' internal addresses 326 (i.e., the addresses used to represent the external hosts in the 327 internal realm) are unchanged (i.e., not NAT-ed). Therefore, the 328 above requirement is met without additional work. 330 o For NAT64, the NAT devices belonging to a redundancy group SHOULD 331 be configured with an identical Prefix64. Since the NAT64 uses 332 stateless address translation for the external hosts, using the 333 same Prefix64 in the Backup NAT can guarantee the internal hosts 334 to see the same internal addresses for the external hosts. 336 o For NAT46, NAT devices in a redundancy group SHOULD be configured 337 with an identical IPv4 address pool. A subset of translation 338 state information SHOULD be synchronized among these NAT devices 339 through a dedicated state synchronization protocol such as 340 [I-D.xu-behave-nat-state-sync]. This translation state ensures 341 that the Backup NAT, once taking over as a Primary NAT, will 342 assign the same IPv4 addresses to the external IPv6 hosts for the 343 internal IPv4 hosts. 345 6.2. External Realm 347 Each NAT device in a NAT redundancy group is configured with a 348 different external address pool. A route to that external pool is 349 then announced into the external realm by the NAT device or the NAT 350 immediate router. 352 o For NAT44, DS-Lite and NAT64: NAT devices SHOULD be configured 353 with different external IPv4 address pools. These address pools 354 are not overlapped. Otherwise, when the Primary NAT fails and the 355 Backup NAT takes over the Primary NAT, a NAT collision may happen. 356 For example, assuming a Primary NAT NAT-ed internal host Host-A to 357 IPv4-A. IPv4-A is an address which belongs to the external 358 address pool. If the Backup NAT after taking over the primary NAT 359 was configured with the same pool, the Backup NAT MAY assign the 360 same IPv4-A to another internal host Host-B. So, Host-B may 361 receive datagrams originally targeted for Host-A. This might 362 cause confusion to Host-B. In addition, by using different 363 external address pools on each NAT device, incoming datagrams of a 364 given session from the external hosts are ensured to always 365 traverse through the Backup NAT device after the Primary NAT 366 failover happens. 368 o For NAT46, the issue occurred in NAT44 and NAT64 cases will not 369 happen. NAT46 relies on stateless address translation for the 370 internal hosts. The Primary and Backup NAT SHOULD use the same 371 external Prefix64, hence the external hosts can use the Backup 372 NAT46 to reach the internal hosts. In Cold Standby mechanism, the 373 Primary and Backup NAT MAY use different Prefix64s. In contrast, 374 the Primary and Backup NAT in Hot Standby mechanism MUST use an 375 identical Prefix64. 377 6.3. NAT Reachability Announcement 379 In order to force the IP datagrams from the internal realm to always 380 traverse through the Primary NAT to the external realm, the Primary 381 NAT SHOULD announce into the internal realm a route towards the 382 external realm. 384 o For NAT44, the Primary NAT announces an IPv4 default route into 385 the internal realm. 387 o For DS-Lite, the Primary NAT announces a host route into the 388 internal realm. 390 o For NAT64, the Primary NAT announces a route for the Prefix64 into 391 the internal realm. 393 o For NAT46, the Primary NAT announces a route for the internal 394 address pool into the internal realm (If the internal address pool 395 can be aggregated to one prefix). 397 The Primary NAT SHOULD attempt to withdraw its previously announced 398 routes when it ceases the Primary role due to pre-configured 399 conditions, e.g.- it loses the IP connectivity to the external realm. 401 When the Primary NAT fails and the Backup NAT takes over, datagrams 402 from the internal hosts destined for the external realm SHOULD pass 403 through the Backup NAT. Hence, when the Backup NAT is manually 404 configured to switch over to become the Primary NAT, the Backup NAT 405 (or associated router) SHOULD announce the same route into the 406 internal realm, but the routing cost of this route MUST be set to a 407 higher value than the route announced by the Primary NAT. 409 Alternatively, the Primary NAT announces several more specific routes 410 into the internal realm while the Backup NAT announces an aggregate 411 route. Taken the NAT46 as an example, assuming the internal address 412 pool is 10.0.0.0/8, the Primary NAT announces two more specific 413 routes to 10.0.0.0/9 and 10.128.0.0/9 respectively while the Backup 414 NAT announces an aggregate route to 10.0.0.0/8. In case the Primary 415 NAT and the Backup NAT are automatically elected through a dedicated 416 election process, the Backup NAT would be elected as a new Primary 417 NAT once the old Primary one fails, so it is not necessary for the 418 Backup NAT to make the above route announcements until it is elected 419 as a new Primary NAT. 421 In order for the external hosts to traverse through the NAT to reach 422 the internal hosts, the Primary and Backup NAT SHOULD announce a 423 route of its own external address pool into the external realm. 425 7. Hot Standby Mode 427 7.1. Internal Realm 429 The procedure is identical to Section 6.1. 431 7.2. External Realm 433 To preserve the established sessions during the failover and to keep 434 the internal addresses unchanged for the external hosts, the external 435 addresses for the internal hosts MUST also be preserved. To preserve 436 the external address of the internal host after NAT-ed, the NAT 437 devices in a redundancy group MUST use an identical external address 438 pool. In addition, they MUST assign the same external address (or 439 address/port pair) to a given internal host. 441 o For NAT46, the Primary NAT and Backup NAT MUST use an identical 442 Prefix64. 444 o For NAT44, DS-Lite and NAT64, the NAT devices in a redundancy 445 group MUST use the same external address pool and the translation 446 states on the Primary NAT device MUST be synchronized to the 447 Backup NAT(s) in a timely fashion. 449 7.3. NAT Reachability Announcement 451 In order to force IP datagrams between the internal realm and the 452 external realm always traverse through the Primary NAT, the Primary 453 NAT (or its associated router) SHOULD announce into the internal 454 realm a route towards the external realm and announce into the 455 external realm a route towards the external address pool. 457 Once the connectivity to either the external realm or the internal 458 realm is lost, the Primary NAT device itself or a third party SHOULD 459 attempt to withdraw the above routes. If the Primary NAT and the 460 Backup NAT are specified manually, the Backup NAT device (or its 461 associated router) SHOULD also announce those routes, but with higher 462 enough cost or larger granularity, so as to prepare for the failover. 464 When the Primary NAT fails, the datagrams towards the external realm 465 will pass through the Backup NAT device. In case the Primary NAT and 466 the Backup are automatically elected through a dedicated election 467 procedure, the Backup NAT would be elected as a new Primary NAT when 468 the old Primary NAT device fails. Consequently, it is not necessary 469 for the Backup NAT to make the above route announcement until it is 470 elected as a new Primary NAT. 472 8. IANA Considerations 474 This document makes no request of IANA. 476 Note to RFC Editor: this section may be removed on publication as an 477 RFC. 479 9. Security Considerations 481 TBD. 483 10. Acknowledgements 485 The author would like to thank Dan Wing and Dave Thaler for their 486 insightful comments and reviews, and thank Dacheng Zhang and Xuewei 487 Wang for their valuable editorial reviews. 489 11. References 491 11.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 11.2. Informative References 498 [I-D.ietf-behave-address-format] 499 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 500 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 501 draft-ietf-behave-address-format-10 (work in progress), 502 August 2010. 504 [I-D.ietf-behave-v6v4-xlate-stateful] 505 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 506 NAT64: Network Address and Protocol Translation from IPv6 507 Clients to IPv4 Servers", 508 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 509 progress), July 2010. 511 [I-D.ietf-softwire-dual-stack-lite] 512 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 513 Stack Lite Broadband Deployments Following IPv4 514 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 515 in progress), August 2010. 517 [I-D.shirasaki-nat444-isp-shared-addr] 518 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 519 and H. Ashida, "NAT444 addressing models", 520 draft-shirasaki-nat444-isp-shared-addr-04 (work in 521 progress), July 2010. 523 [I-D.xu-behave-nat-state-sync] 524 Cheng, D. and X. Xu, "NAT State Synchronization Using 525 SCSP", draft-xu-behave-nat-state-sync-02 (work in 526 progress), August 2010. 528 [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, 529 "Server Cache Synchronization Protocol (SCSP)", RFC 2334, 530 April 1998. 532 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 533 Translator (NAT) Terminology and Considerations", 534 RFC 2663, August 1999. 536 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 537 (VPLS) Using BGP for Auto-Discovery and Signaling", 538 RFC 4761, January 2007. 540 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 541 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 542 RFC 4762, January 2007. 544 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 545 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 547 Appendix A. State Synchronization Protocol Considerations 549 [I-D.xu-behave-nat-state-sync] defines a candidate solution to NAT 550 state synchronization by using Server Cache Synchronization Protocol 551 (SCSP) [RFC2334]. For more information about the proposed solution, 552 refer to [I-D.xu-behave-nat-state-sync]. 554 [[Note: What to do with this section?]] 556 Appendix B. Election Protocol Considerations 558 [[Note: What to do with this section?]] 560 An election process and associated protocol(s) can be used to 561 automatically elect one NAT device among a NAT redundancy group as 562 the Primary NAT and the others as Backup NATs. Once the Primary NAT 563 fails, the Backup NAT with the highest priority SHOULD take over the 564 Primary NAT role after a short delay. The election protocol is also 565 used to track the connectivity to the external realm and the internal 566 realm. Once connections to the external realm or the internal realm 567 lost, the NAT device is not qualified to be the Primary NAT and it 568 will withdraw the route towards the external realm announced 569 previously. In the case of hot standby, it SHOULD also withdraw the 570 route towards the external address pool. 572 As an implementation example, VRRP [RFC5798] can be used as the 573 automatic election protocol. In addition, an interface tracking 574 mechanism can also be used to adjust the priority to influence the 575 election results. 577 If two NAT devices are directly connected via an Ethernet network, 578 VRRP can run directly on the Ethernet interfaces. Otherwise, some 579 extra configuration or protocol changes need to be implemented. One 580 option is to create conditions for VRRP to run among these devices. 581 For example, to create a VPLS [RFC4761][RFC4762] instance and enable 582 IP functions and run VRRP on those VLAN interfaces which are bound to 583 that VPLS instance. If enabling IP on those interfaces is not 584 supported, the following trick to realize the same goal, but at a 585 cost of consuming two physical interfaces on each NAT router: create 586 a VPLS instance among a set of NAT devices, and on each of them one 587 Ethernet interface is bound to that VPLS instance, and another IP- 588 enabled Ethernet interface is locally connected with that interface. 589 Then VRRP can run on those IP enabled Ethernet interfaces which are 590 all connected to that VPLS instance. Another option is to extend 591 VRRP so that VRRP neighbors can be specified manually and VRRP 592 messages can be exchanged directly among VRRP neighbors in unicast. 594 VRRP is only an implementation example of the election process. 595 Other protocols MAY be used to manage the roles of Primary and 596 Backup. 598 Authors' Addresses 600 Xiaohu Xu 601 Huawei Technologies Co.,Ltd 602 KuiKe Building, No.9 Xinxi Rd., 603 Hai-Dian District, Beijing 100085 604 P.R. China 606 Email: xuxh@huawei.com 608 Mohamed Boucadair 609 France Telecom 610 Rennes 611 France 613 Email: mohamed.boucadair@orange-ftgroup.com 615 Yiu L. Lee 616 Comcast 618 Email: yiu_lee@cable.comcast.com 619 URI: http://www.comcast.com 621 Gang Chen 622 China Mobile 623 53A,Xibianmennei Ave. 624 Beijing, 100053 625 P.R.China 627 Email: phdgang@gmail.com