RFC 6736
Diameter Network Address and Port Translation Control Application
Pages: 58
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 40 to 58
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.
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.
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.
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 |
+-------------------------------------------------------+
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].
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
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.
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.
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.
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.
<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).
< 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.
<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;"
}
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.
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
}
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.
[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.
[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.
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