Dean Cheng Xiaohu Xu Joel Halpern Mohamed Boucadair IETF76, Hiroshima NAT State Synchronization using SCSP draft-xu-nat-state-sync-00

SCSP – A Protocol for Data Cache Synchronization Server Cache Synchronization Protocol (SCSP - RFC2334) solves a general server synchronization/cache-replication problem for distributed databases. SCSP uses link-state based algorithm to reliably flood database entries among participating servers. SCSP defines application-independent protocol mechanisms and requires applications to define their own formats for cache records, called Cache State Advertisement (CSA). This document specifies a method of using SCSP to achieve NAT state synchronization among NAT devices in a redundancy group including associated CSA format.

Requirements for NAT Devices Deployed with Redundancy Achieve hot-standby and load balancing, data synchronization is a MUST. Reliability and robustness are very much desired during data synchronization process. Stateful contents in data cache maintained by NAT MUST be replicated and synchronized on all participating NAT devices in a redundancy group. When a NAT device in a redundancy group fails, all existing NAT sessions must survive without any perceived impact on traffic (e.g., severe delay, loss, etc.)

Use SCSP to Sync NAT Database Multiple NAT devices deployed on the border between two IP domains form a redundancy group which, possibly along with other redundancy groups, belong to a SCSP Server Group (SG), identified by SGID. Within a redundancy group, there is a primary and one or more backup devices. When the primary NAT device fails, a new primary NAT device is elected. For each NAT type, a separate SCSP Protocol ID (PID) is assigned by IANA. Currently NAT type includes NAT44, NAT64, and NAT46. The method described is applicable to stateful NAT devices only.

NAT State Refreshment Mechanism Only primary NAT device can create new cache entries. NAT database entries are aged. The primary device is responsible to re-originate and re-flood them before aging out for active entries. After a switchover, the newly elected primary NAT device MUST re-originate all cache entries that were originated by the previous primary NAT device, with NAT contents remain the same followed by a reliable flooding defined by SCSP.

SCSP Message Mandatory Common Part | Protocol ID | Server Group ID | | Unused | Flags | | Sender ID Len | Recvr ID Len | Number of Records | / / / Sender ID (Variable Length) / / / / / / Receiver ID (Variable Length) / / /

Values for the SCSP “Mandatory Common Part” Protocol ID = TBD  There is a separate Protocol ID for NAT44, NAT64, and NAT46, assigned by IANA. Server Group ID = NAT device redundancy group ID Sender ID Len  = 4, if IPv4 address is used  =16, if IPv6 address is used.  Per RFC2334, an identifier assigned to a server (in this case, a NAT device), might be the protocol address of the sending server. Recvr ID Len  = 4, if IPv4 address is used  =16, if IPv6 address is used.  Per RFC2334, an identifier assigned to a server (in this case, a NAT device), might be the protocol address of the receiving server.

Values for the SCSP “CSAS Record” Cache Key Len = 4  This 4-byte opaque string is generated by the NAT device that originates the CSAS. Originator ID Len  = 4, if IPv4 address is used  = 16, if IPv6 address is used.  Per RFC2334, an identifier assigned to a server (in this case, a NAT device) might be the protocol address of the server.

NAT Specific CSA | Protocol | Option Length | Unused | | Port Mapped from | Port Mapped to | / / / Address Mapped from (Specific to NAT type) / / / / / / Address Mapped to (Specific to NAT type) / / / / / / TLV Options (Variable Length) / / /

The Next … Authors would like to solicit comments with discussion on mailing list at this time If there is enough interest, we’ll propose to move this I-D as a working group document