Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6736

Diameter Network Address and Port Translation Control Application

Pages: 58
Proposed Standard
Part 3 of 3 – Pages 40 to 58
First   Prev   None

Top   ToC   RFC6736 - Page 40   prevText

9. Accounting Commands

The DNCA reuses session-based accounting as defined in the Diameter base protocol [RFC6733] to report the bindings per endpoint. This reporting is achieved by sending Diameter Accounting-Request (ACR) commands [Start, Interim, and Stop] from the DNCA Diameter peer within the NAT device to its associated DNCA Diameter peer within the NAT controller. The DNCA Diameter peer within the NAT device sends an ACR Start on receiving an NCR with NC-Request-Type AVP set to INITIAL_REQUEST for a session or on creation of the first binding for a session requested in an earlier NCR. DNCA may send ACR Interim updates, if required, either due to a change in bindings resulting from an NCR with NC- Request-Type AVP set to UPDATE_REQUEST, periodically as specified in Acct-Interim-Interval by the DNCA Diameter peer within the NAT controller, or when it creates or tears down bindings. An ACR Stop is sent by the DNCA Diameter peer within the NAT device on receiving an STR message. The function of correlating the multiple bindings used by an endpoint at any given time is relegated to the post processor. The DNCA Diameter peer within the NAT device may trigger an Interim accounting record when the maximum number of bindings, if received in an NCR, is reached.

9.1. NAT Control Accounting Messages

The ACR and ACA messages are reused as defined in the Diameter base protocol [RFC6733] for exchanging endpoint NAT-binding details between the DNCA Diameter peers. The DNCA Application ID is used in the accounting commands. The ACR contains one or more optional NAT- Control-Record AVPs to report the bindings. The NAT device indicates the number of allocated NAT-bindings to the NAT controller using the Current-NAT-Bindings AVP. This number needs to match the number of bindings identified as active within the NAT-Control-Record AVP.

9.2. NAT Control Accounting AVPs

In addition to AVPs for ACR specified in [RFC6733], the DNCA Diameter peer within the NAT device must add the NAT-Control-Record AVP.
Top   ToC   RFC6736 - Page 41

9.2.1. NAT-Control-Record

The NAT-Control-Record AVP (AVP code 605) is of type Grouped. It describes a binding and its status. If NAT-Control-Binding-Status is set to Created, Event-Timestamp indicates the binding creation time. If NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates the binding removal time. If NAT-Control-Binding-Status is active, Event-Timestamp need not be present; if a value is present, it indicates that binding is active at the given time. NAT-Control-Record ::= < AVP Header: 605 > { NAT-Control-Definition } { NAT-Control-Binding-Status } [ Event-Timestamp ]

9.2.2. NAT-Control-Binding-Status

The NAT-Control-Binding-Status AVP (AVP code 606) is of type enumerated. It indicates the status of the binding: created, removed, or active. The following values are defined: Created (1) NAT-binding is created. Active (2) NAT-binding is active. Removed (3) NAT-binding was removed.

9.2.3. Current-NAT-Bindings

The Current-NAT-Bindings AVP (AVP code 607) is of type Unsigned32. It indicates the number of NAT-bindings active on the NAT device.

10. AVP Occurrence Tables

The following sections present the AVPs defined in this document and specify the Diameter messages in which they can be present. Note: AVPs that can only be present within a Grouped AVP are not represented in this table.
Top   ToC   RFC6736 - Page 42
   The table uses the following symbols:

      0         The AVP MUST NOT be present in the message.

      0+        Zero or more instances of the AVP can be present in the
                message.

      0-1       Zero or one instance of the AVP can be present in the
                message.  It is considered an error if there is more
                than one instance of the AVP.

      1         One instance of the AVP MUST be present in the message.

      1+        At least one instance of the AVP MUST be present in the
                message.

10.1. DNCA AVP Table for NAT Control Initial and Update Requests

The following table lists DNCA-specific AVPs that have to be present in NCRs and NCAs with the NC-Request-Type set to INITIAL_REQUEST or UPDATE_REQUEST. +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name NCR NCA | +-------------------------------------------------------+ |NC-Request-Type 1 1 | |NAT-Control-Install 0-1 0 | |NAT-Control-Remove 0-1 0 | |NAT-Control-Definition 0 0 | |Current-NAT-Bindings 0 0 | |Duplicate-Session-Id 0 0-1 | +-------------------------------------------------------+ Note that any combination of NAT-Control-Install and NAT-Control- Remove AVPs could be present in an update or initial requests. Consider the following examples: Neither the NAT-Control-Install AVP nor the NAT-Control-Remove AVP is present: This could, for example, be the case if the NAT controller would only want to receive accounting information but not control NAT-bindings. Only NAT-Control-Install AVP is present: This could, for example, be the case if a new NAT-binding is installed for an existing session.
Top   ToC   RFC6736 - Page 43
      Only NAT-Control-Remove AVP is present: This could, for example,
      be the case if a new NAT-binding is removed from an existing
      session.

      Both, NAT-Control-Install AVP and NAT-Control-Remove AVP are
      present: This could, for example. be the case if a formerly
      created NAT-binding is removed and a new NAT-binding is
      established within the same request.

10.2. DNCA AVP Table for Session Query Requests

The following table lists DNCA-specific AVPs that have to be present in NCRs and NCAs with the NC-Request-Type set to QUERY_REQUEST. +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name NCR NCA | +-------------------------------------------------------+ |NC-Request-Type 1 1 | |NAT-Control-Install 0 0 | |NAT-Control-Remove 0 0 | |NAT-Control-Definition 0 0+ | |NAT-External-Address 0+ 0 | |Current-NAT-Bindings 0 1 | |Duplicate-Session-Id 0 0 | +-------------------------------------------------------+

10.3. DNCA AVP Table for Accounting Messages

The following table lists DNCA-specific AVPs, which may or may not be present in ACR and ACA messages. +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name ACR ACA | +-------------------------------------------------------+ |NAT-Control-Record 0+ 0 | |Current-NAT-Bindings 1 0 | +-------------------------------------------------------+
Top   ToC   RFC6736 - Page 44

11. IANA Considerations

This section contains either the namespaces that have been created in this specification or the values assigned to existing namespaces managed by IANA. In the subsections below, when we speak about review by a Designated Expert [RFC5226], please note that the Designated Expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list.

11.1. Application Identifier

This specification assigns the value 12, 'Diameter NAT Control Application', to the Application Identifier namespace defined in [RFC6733]. See Section 4 for more information.

11.2. Command Codes

This specification uses the value 330 from the Command code namespace defined in [RFC6733] for the NAT-Control-Request (NCR) and NAT- Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 for more information on these commands.

11.3. AVP Codes

This specification assigns the values 595-607 from the AVP Code namespace defined in [RFC6733]. See Section 8.7 for the assignment of the namespace in this specification.

11.4. Result-Code AVP Values

This specification assigns the values 4014 and 5042-5047 from the Result-Code AVP value namespace defined in [RFC6733]. See Section 8.2 for the assignment of the namespace in this specification.

11.5. NC-Request-Type AVP

As defined in Section 8.7.1, the NC-Request-Type AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].
Top   ToC   RFC6736 - Page 45

11.6. NAT-External-Port-Style AVP

As defined in Section 8.7.10, the NAT-External-Port-Style AVP includes Enumerated type value 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].

11.7. NAT-Control-Binding-Status AVP

As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].

12. Security Considerations

This document describes procedures for controlling NAT-related attributes and parameters by an entity, which is non-local to the device performing NAT. This section discusses security considerations for DNCA. This includes the interactions between the Diameter peers within a NAT controller and a NAT device as well as general considerations for a NAT-control in a service provider network. Security between a NAT controller and a NAT device has a number of components: authentication, authorization, integrity, and confidentiality. "Authentication" refers to confirming the identity of an originator for all datagrams received from the originator. Lack of authentication of Diameter messages between the Diameter peers can jeopardize the fundamental service of the peering network elements. A consequence of not authenticating the message sender by the recipient would be that an attacker could spoof the identity of a "legitimate" authorizing entity in order to change the behavior of the receiver. An attacker could, for example, launch a DoS attack by setting the maximum number of bindings for a session on the NAT device to zero; provisioning bindings on a NAT device that includes IP addresses already in use in other parts of the network; or requesting session termination of the Diameter session and hampering an endpoint's (i.e., a user's) connectivity. Lack of authentication of a NAT device to a NAT controller could lead to situations where the NAT device could provide a wrong view of the resources (i.e., NAT-bindings). In addition, a NAT-binding Predefined template on the NAT device could be configured differently than expected by the NAT controller. If either of the two DNCA Diameter peers fail to provide the required credentials, the failure should be subject to logging. The corresponding logging infrastructure of the operator SHOULD be
Top   ToC   RFC6736 - Page 46
   built in a way that it can mitigate potential DoS attacks resulting
   from large amounts of logging events.  This could include proper
   dimensioning of the logging infrastructure combined with policing the
   maximum amount of logging events accepted by the logging system to a
   threshold which the system is known to be able to handle.

   "Authorization" refers to whether a particular authorizing entity is
   authorized to signal a network element request for one or more
   applications, adhering to a certain policy profile.  Failing the
   authorization process might indicate a resource theft attempt or
   failure due to administrative and/or credential deficiencies.  In
   either case, the network element should take the proper measures to
   log such attempts.

   Integrity is required to ensure that a Diameter message exchanged
   between the Diameter peers has not been maliciously altered by
   intermediate devices.  The result of a lack of data integrity
   enforcement in an untrusted environment could be that an impostor
   will alter the messages exchanged between the peers.  This could
   cause a change of behavior of the peers, including the potential of a
   DoS.

   Confidentiality protection of Diameter messages ensures that the
   signaling data is accessible only to the authorized entities.  When
   signaling messages between the DNCA Diameter peers traverse untrusted
   networks, lack of confidentiality will allow eavesdropping and
   traffic analysis.

   Diameter offers security mechanisms to deal with the functionality
   demanded above.  DNCA makes use of the capabilities offered by
   Diameter and the underlying transport protocols to deliver these
   requirements (see Section 5.1).  If the DNCA communication traverses
   untrusted networks, messages between DNCA Diameter peers SHOULD be
   secured using either IPsec or TLS.  Please refer to [RFC6733],
   Section 13 for details.  DNCA Diameter peers SHOULD perform bilateral
   authentication, authorization, as well as procedures to ensure
   integrity and confidentiality of the information exchange.  In
   addition, the Session-Id chosen for a particular Diameter session
   SHOULD be chosen in a way that it is hard to guess in order to
   mitigate issues through potential message replay.

   DNCA Diameter peers SHOULD have a mutual trust setup.  This document
   does not specify a mechanism for authorization between the DNCA
   Diameter peers.  The DNCA Diameter peers SHOULD be provided with
   sufficient information to make an authorization decision.  The
   information can come from various sources, for example, the peering
   devices could store local authentication policy, listing the
   identities of authorized peers.
Top   ToC   RFC6736 - Page 47
   Any mechanism or protocol providing control of a NAT device, and DNCA
   is an example of such a control mechanism, could allow for misuse of
   the NAT device given that it enables the definition of per-
   destination or per-source rules.  Misuse could include anti-
   competitive practices among providers, censorship, crime, etc.  NAT-
   control could be used as a tool for preventing or redirecting access
   to particular sites.  For instance, by controlling the NAT-bindings,
   one could ensure that endpoints aren't able to receive particular
   flows, or that those flows are redirected to a relay that snoops or
   tampers with traffic instead of directly forwarding the traffic to
   the intended endpoint.  In addition, one could set up a binding in a
   way that the source IP address used is one of a relay so that traffic
   coming back can be snooped on or interfered with.  The operator also
   needs to consider security threats resulting from unplanned
   termination of the DNCA session.  Unplanned session termination,
   which could happen due to, e.g., an attacker taking down the NAT
   controller, leads to the NAT device cleaning up the state associated
   with this session after a grace period.  If the grace period is set
   to zero, the endpoint will experience an immediate loss of
   connectivity to services reachable through the NAT device following
   the termination of the DNCA session.The protections on DNCA and its
   Diameter protocol exchanges don't prevent such abuses of NAT-control.
   Prevention of misuse or misconfiguration of a NAT device by an
   authorized NAT controller is beyond the scope of this protocol
   specification.  A service provider deploying DNCA needs to make sure
   that higher-layer processes and procedures are put in place that
   allow them to detect and mitigate misuses.

13. Examples

This section shows example DNCA message content and exchange.

13.1. DNCA Session Establishment Example

Figure 15 depicts a typical call flow for DNCA session establishment. In this example, the NAT controller does the following: a. requests a maximum of 100 NAT-bindings for the endpoint. b. defines a static binding for a TCP connection that associates the internal IP Address:Port 192.0.2.1:80 with the external IP Address:Port 198.51.100.1:80 for the endpoint. c. requests the use of a preconfigured template called "local- policy" while creating NAT-bindings for the endpoint.
Top   ToC   RFC6736 - Page 48
   endpoint             NAT controller (within NAS)           NAT device
      |                            |                               |
      |                            |                               |
      |      1. Trigger            |                               |
      |--------------------------->|                               |
      |       +-------------------------------------+              |
      |       |  2. Determine that NAT control      |              |
      |       |     is required for the endpoint    |              |
      |       +-------------------------------------+              |
      |                            |                               |
      |                            |                               |
      |                           ...................................
      |                           .|   3. Diameter Base CER/CEA    |.
      |                           .|<----------------------------->|.
      |                           ...................................
      |                            |                               |
      |                            |                               |
      |                            |         4.  NCR               |
      |                            |------------------------------>|
      |                            |                               |
      |                            |                     5. DNCA session
      |                            |                        established
      |                            |                               |
      |                            |         6.  NCA               |
      |                            |<------------------------------|
      |                            |                               |
      |                            |                               |
      |                  7. Data traffic                           |
      |----------------------------------------------------------->|
      |                            |                               |
      |                            |                               |
      |                            |                    8. NAT-bindings
      |                            |                     created as per
      |                            |                   directives in the
      |                            |                       DNCA session
      |                            |                               |


                Figure 15: Initial NAT-Control-Request and
                       Session Establishment Example

   Detailed description of the steps shown in Figure 15:

   1.  The NAT controller (co-located with the NAS here) creates state
       for an endpoint based on a trigger.  This could, for example, be
       the successful establishment of a Point-to-Point Protocol (PPP)
       [RFC1661] access session.
Top   ToC   RFC6736 - Page 49
   2.  Based on the configuration of the DNCA Diameter peer within the
       NAT controller, the NAT controller determines that NAT-control is
       required and is to be enforced at a NAT device.

   3.  If there is no Diameter session already established with the DNCA
       Diameter peer within NAT device, a Diameter connection is
       established and Diameter Base CER/CEA are exchanged.

   4.  The NAT-Controller creates an NCR message (see below) and sends
       it to the NAT device.  This example shows IPv4 to IPv4 address
       and port translation.  For IPv6 to IPv4 translation, the Framed-
       IP-Address AVP would be replaced by the Framed-IPv6-Address AVP
       with the value set to the IPv6 address of the endpoint.

     < NC-Request > ::= < Diameter Header: 330, REQ, PXY>
                      Session-Id =  "natC.example.com:33041;23432;"
                      Auth-Application-Id = <DNCA Application ID>
                      Origin-Host = "natC.example.com"
                      Origin-Realm = "example.com"
                      Destination-Realm = "example.com"
                      Destination-Host = "nat-device.example.com"
                      NC-Request-Type = INITIAL_REQUEST
                      User-Name = "subscriber_example1"
                      Framed-IP-Address = "192.0.2.1"
                      NAT-Control-Install = {
                           NAT-Control-Definition = {
                              Protocol = TCP
                              Direction = OUT
                              NAT-Internal-Address = {
                                   Framed-IP-Address = "192.0.2.1"
                                   Port = 80
                              }
                              NAT-External-Address = {
                                   Framed-IP-Address = "198.51.100.1"
                                   Port = 80
                              }
                           }
                           Max-NAT-Bindings = 100
                           NAT-Control-Binding-Template = "local-policy"
                      }

   5.  The NAT device establishes a DNCA session as it is able to comply
       with the request.

   6.  The NAT device sends an NCA to indicate the successful completion
       of the request.
Top   ToC   RFC6736 - Page 50
      <NC-Answer> ::= < Diameter Header: 330, PXY >
                       Session-Id =  "natC.example.com:33041;23432;"
                       Origin-Host = "nat-device.example.com"
                       Origin-Realm = "example.com"
                       NC-Request-Type = INITIAL_REQUEST
                       Result-Code = DIAMETER_SUCCESS


   7.  The endpoint sends packets that reach the NAT device.

   8.  The NAT device performs NAT for traffic received from the
       endpoint with source address 192.0.2.1.  Traffic with source IP
       address 192.0.2.1 and port 80 are translated to the external IP
       address 198.51.100.1 and port 80.  Traffic with source IP address
       192.0.2.1 and a source port different from 80 will be translated
       to IP address 198.51.100.1 and a port chosen by the NAT device.
       Note that this example assumes that the NAT device follows
       typical binding allocation rules for endpoints, in that only a
       single external IP address is used for all traffic received from
       a single IP address of an endpoint.  The NAT device will allow a
       maximum of 100 NAT-bindings be created for the endpoint.

13.2. DNCA Session Update with Port Style Example

This section gives an example for a DNCA session update: A new set of NAT-bindings is requested for an existing session. The request contains a directive ( the "NAT-External-Port-Style" AVP set to FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT device to maintain port-sequence and port-oddity for the newly created NAT-bindings. In the example shown, the internal ports are UDP port 1036 and 1037. The NAT device follows the directive selects the external ports accordingly. The NAT device would, for example, create a mapping of 192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to 198.51.100.1:5057, thereby maintaining port oddity (1036->5056, 1037->5057) and sequence ( the consecutive internal ports 1036 and 1037 map to the consecutive external ports 5056 and 5057).
Top   ToC   RFC6736 - Page 51
      < NC-Request > ::= < Diameter Header: 330, REQ, PXY>
                       Session-Id =  "natC.example.com:33041;23432;"
                       Auth-Application-Id = <DNCA Application ID>
                       Origin-Host = "natC.example.com"
                       Origin-Realm = "example.com"
                       Destination-Realm = "example.com"
                       Destination-Host = "nat-device.example.com"
                       NC-Request-Type = UPDATE_REQUEST
                       NAT-Control-Install = {
                           NAT-Control-Definition = {
                               Protocol = UDP
                               Direction = OUT
                               NAT-Internal-Address = {
                                    Framed-IP-Address = "192.0.2.1"
                                    Port = 1035
                               }
                           }
                           NAT-Control-Definition = {
                               Protocol = UDP
                               Direction = OUT
                               NAT-Internal-Address = {
                                    Framed-IP-Address = "192.0.2.1"
                                    Port = 1036
                               }
                           }
                           NAT-External-Port-
                                  Style = FOLLOW_INTERNAL_PORT_STYLE
                       }

13.3. DNCA Session Query Example

This section shows an example for DNCA session query for a subscriber whose internal IP Address is 192.0.2.1. < NC-Request > ::= < Diameter Header: 330, REQ, PXY> Auth-Application-Id = <DNCA Application ID> Origin-Host = "natC.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "nat-device.example.com" NC-Request-Type = QUERY_REQUEST Framed-IP-Address = "192.0.2.1" The NAT device constructs an NCA to report all currently active NAT- bindings whose internal address is 192.0.2.1.
Top   ToC   RFC6736 - Page 52
      <NC-Answer> ::= < Diameter Header: 330, PXY >
                    Origin-Host = "nat-device.example.com"
                    Origin-Realm = "example.com"
                    NC-Request-Type = QUERY_REQUEST
                    NAT-Control-Definition = {
                            Protocol = TCP
                            Direction = OUT
                            NAT-Internal-Address = {
                                Framed-IP-Address = "192.0.2.1"
                                Port = 80
                               }
                            NAT-External-Address = {
                                 Framed-IP-Address = "198.51.100.1"
                                 Port = 80
                               }
                            Session-Id = "natC.example.com:33041;23432;"
                    }
                    NAT-Control-Definition = {
                            Protocol = TCP
                            Direction = OUT
                            NAT-Internal-Address = {
                                Framed-IP-Address = "192.0.2.1"
                                Port = 1036
                               }
                            NAT-External-Address = {
                                 Framed-IP-Address = "198.51.100.1"
                                 Port = 5056
                               }
                            Session-Id = "natC.example.com:33041;23432;"
                    }
                    NAT-Control-Definition = {
                            Protocol = TCP
                            Direction = OUT
                            NAT-Internal-Address = {
                                Framed-IP-Address = "192.0.2.1"
                                Port = 1037
                               }
                            NAT-External-Address = {
                                 Framed-IP-Address = "198.51.100.1"
                                 Port = 5057
                               }
                            Session-Id = "natC.example.com:33041;23432;"
                       }
Top   ToC   RFC6736 - Page 53

13.4. DNCA Session Termination Example

In this example the NAT controller decides to terminate the previously established DNCA session. This could, for example, be the case as a result of an access session (e.g., a PPP session) associated with an endpoint having been torn down. NAT controller NAT device | | | | +--------------+ | | 1. Trigger | | +--------------+ | | | | | | 2. STR | |-------------------------------------->| | | | 3. DNCA session | lookup | 4. ACR | |<--------------------------------------| | | | 5. ACA | |-------------------------------------->| | | | | | 6. DNCA bindings | and session cleanup | | | 7. STA | |<--------------------------------------| | | Figure 20: NAT Control Session Termination Example The following steps describe the sequence of events for tearing down the DNCA session in the example above: 1. The NAT controller receives a trigger that a DNCA session associated with a specific endpoint should be terminated. An example event could be the termination of the PPP [RFC1661] access session to an endpoint in a NAS. The NAS correspondingly triggers the NAT controller request to tear down the associated DNCA session.
Top   ToC   RFC6736 - Page 54
   2.  The NAT controller creates the required NCR message and sends it
       to the NAT device:

      < STR >     ::= < Diameter Header: 275, REQ, PXY>
                       Session-Id =  "natC.example.com:33041;23432;"
                       Auth-Application-Id = <DNCA Application ID>
                       Origin-Host = "natC.example.com"
                       Origin-Realm = "example.com"
                       Destination-Realm = "example.com"
                       Destination-Host = "nat-device.example.com"
                       Termination-Cause = DIAMETER_LOGOUT

   3.  The NAT device looks up the DNCA session based on the Session-Id
       AVP and finds a previously established active session.

   4.  The NAT device reports all NAT-bindings established for that
       subscriber using an ACR:
      < ACR >     ::= < Diameter Header: 271, REQ, PXY>
                       Session-Id =  "natC.example.com:33041;23432;"
                       Auth-Application-Id = <DNCA Application ID>
                       Origin-Host = "nat-device.example.com"
                       Origin-Realm = "example.com"
                       Destination-Realm = "example.com"
                       Destination-Host = "natC.example.com"
                       Accounting-Record-Type = STOP_RECORD
                       Accounting-Record-Number = 1
                       NAT-Control-Record = {
                           NAT-Control-Definition = {
                               Protocol = TCP
                               Direction = OUT
                               NAT-Internal-Address = {
                                   Framed-IP-Address = "192.0.2.1"
                                   Port = 5001
                                  }
                               NAT-External-Address = {
                                    Framed-IP-Address = "198.51.100.1"
                                    Port = 7777
                                  }
                              }
                             NAT-Control-Binding-Status = Removed
                          }
Top   ToC   RFC6736 - Page 55
   5.  The NAT controller receives and processes the ACR as per its
       configuration.  It responds with an ACA to the NAT device.

      <ACA>      ::= < Diameter Header: 271, PXY >
                       Session-Id =  "natC.example.com:33041;23432;"
                       Origin-Host = "natC.example.com"
                       Origin-Realm = "example.com"
                       Result-Code = DIAMETER_SUCCESS
                       Accounting-Record-Type = STOP_RECORD
                       Accounting-Record-Number = 1

   6.  On receipt of the ACA the NAT device cleans up all NAT-bindings
       and associated session state for the endpoint.

   7.  NAT device sends an STA.  On receipt of the STA the NAT
       controller will clean up the corresponding session state.
      <STA>      ::= < Diameter Header: 275, PXY >
                       Session-Id =  "natC.example.com:33041;23432;"
                       Origin-Host = "nat-device.example.com"
                       Origin-Realm = "example.com"
                       Result-Code = DIAMETER_SUCCESS

14. Acknowledgements

The authors would like to thank Jari Arkko, Wesley Eddy, Stephen Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert Sparks, Martin Stiemerling, Dave Thaler, Hannes Tschofenig, Sean Turner, Shashank Vikram, Greg Weber, and Glen Zorn for their input on this document.

15. References

15.1. Normative References

[ETSIES283034] ETSI, "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN), Network Attachment Sub-System (NASS), e4 interface based on the Diameter protocol.", September 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
Top   ToC   RFC6736 - Page 56
   [RFC4675]       Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
                   Attributes for Virtual LAN and Priority Support",
                   RFC 4675, September 2006.

   [RFC5226]       Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 5226, May 2008.

   [RFC5777]       Korhonen, J., Tschofenig, H., Arumaithurai, M.,
                   Jones, M., and A. Lior, "Traffic Classification and
                   Quality of Service (QoS) Attributes for Diameter",
                   RFC 5777, February 2010.

   [RFC6733]       Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
                   "Diameter Base Protocol", RFC 6733, October 2012.

15.2. Informative References

[CGN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, September 2012. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
Top   ToC   RFC6736 - Page 57
   [RFC3550]       Schulzrinne, H., Casner, S., Frederick, R., and V.
                   Jacobson, "RTP: A Transport Protocol for Real-Time
                   Applications", STD 64, RFC 3550, July 2003.

   [RFC4097]       Barnes, M., "Middlebox Communications (MIDCOM)
                   Protocol Evaluation", RFC 4097, June 2005.

   [RFC5189]       Stiemerling, M., Quittek, J., and T. Taylor,
                   "Middlebox Communication (MIDCOM) Protocol
                   Semantics", RFC 5189, March 2008.

   [RFC6145]       Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
                   Algorithm", RFC 6145, April 2011.

   [RFC6146]       Bagnulo, M., Matthews, P., and I. van Beijnum,
                   "Stateful NAT64: Network Address and Protocol
                   Translation from IPv6 Clients to IPv4 Servers",
                   RFC 6146, April 2011.

   [RFC6241]       Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
                   Bierman, "Network Configuration Protocol (NETCONF)",
                   RFC 6241, June 2011.
Top   ToC   RFC6736 - Page 58

Authors' Addresses

Frank Brockners Cisco Hansaallee 249, 3rd Floor Duesseldorf, Nordrhein-Westfalen 40549 Germany EMail: fbrockne@cisco.com Shwetha Bhandari Cisco Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, Karnataka 560 087 India EMail: shwethab@cisco.com Vaneeta Singh 18, Cambridge Road Bangalore 560008 India EMail: vaneeta.singh@gmail.com Victor Fajardo Telcordia Technologies 1 Telcordia Drive #1S-222 Piscataway, NJ 08854 USA EMail: vf0213@gmail.com