tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6736

 
 
 

Diameter Network Address and Port Translation Control Application

Part 3 of 3, p. 40 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 40 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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