draft-ietf-dime-rfc3588bis-04.txt   draft-ietf-dime-rfc3588bis-05.txt 
DIME V. Fajardo, Ed. DIME V. Fajardo, Ed.
Internet-Draft Toshiba America Research Internet-Draft Toshiba America Research
Intended status: Standards Track J. Arkko Intended status: Standards Track J. Arkko
Expires: December 7, 2007 Ericsson Research Expires: January 7, 2008 Ericsson Research
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
June 5, 2007 July 6, 2007
Diameter Base Protocol Diameter Base Protocol
draft-ietf-dime-rfc3588bis-04.txt draft-ietf-dime-rfc3588bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2007. This Internet-Draft will expire on January 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Diameter base protocol is intended to provide an Authentication, The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility. Diameter is also intended to work in network access or IP mobility. Diameter is also intended to work in
skipping to change at page 3, line 5 skipping to change at page 3, line 5
2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33
3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Command Code ABNF specification . . . . . . . . . . . . . 38 3.2. Command Code ABNF specification . . . . . . . . . . . . . 38
3.3. Diameter Command Naming Conventions . . . . . . . . . . . 40 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 40
4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44
4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46
4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 53 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 52
4.4.1. Example AVP with a Grouped Data type . . . . . . . . 54 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 53
4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56
5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 60 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 59
5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 60 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 59
5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 60 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 59
5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 63 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62
5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 64 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 63
5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 65 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 64
5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 65 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 64
5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 66 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 65
5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 66 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 65
5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 66 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 65
5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 66 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 65
5.4. Disconnecting Peer connections . . . . . . . . . . . . . 66 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 65
5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 67 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 66
5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 67 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 66
5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 68 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 67
5.5. Transport Failure Detection . . . . . . . . . . . . . . . 68 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 67
5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 68 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 67
5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 69 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 68
5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 69 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 68
5.5.4. Failover and Failback Procedures . . . . . . . . . . 69 5.5.4. Failover and Failback Procedures . . . . . . . . . . 68
5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 70 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 69
5.6.1. Incoming connections . . . . . . . . . . . . . . . . 72 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 71
5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 73 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 72
5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 74 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 73
5.6.4. The Election Process . . . . . . . . . . . . . . . . 76 5.6.4. The Election Process . . . . . . . . . . . . . . . . 75
5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 76 5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 75
6. Diameter message processing . . . . . . . . . . . . . . . . . 77 6. Diameter message processing . . . . . . . . . . . . . . . . . 76
6.1. Diameter Request Routing Overview . . . . . . . . . . . . 77 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76
6.1.1. Originating a Request . . . . . . . . . . . . . . . 78 6.1.1. Originating a Request . . . . . . . . . . . . . . . 77
6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 79 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 78
6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 79 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78
6.1.4. Processing Local Requests . . . . . . . . . . . . . 79 6.1.4. Processing Local Requests . . . . . . . . . . . . . 78
6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 79 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 78
6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 80 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 79
6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 80 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 79
6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 80 6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 79
6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 82 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 81
6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 82 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 81
6.2.1. Processing received Answers . . . . . . . . . . . . 83 6.2.1. Processing received Answers . . . . . . . . . . . . 82
6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 83 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 82
6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 84 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 83
6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 84 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 83
6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 84 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 83
6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 85 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 84
6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 85 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 84
6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 85 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 84
6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 85 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 84
6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 85 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 84
6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 85 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 84
6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 86 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 86 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 86 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 85
6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 86 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 85
6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 87 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 86
6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 86
6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 89 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88
6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 89 6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 88
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 89
7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 91 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 90
7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 91
7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 92 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 91
7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 93 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 92
7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 93
7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 94
7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 98 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 97
7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 98 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 97
7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 98 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 97
7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 99 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 98
7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 99
8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 101 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 100
8.1. Authorization Session State Machine . . . . . . . . . . . 102 8.1. Authorization Session State Machine . . . . . . . . . . . 101
8.2. Accounting Session State Machine . . . . . . . . . . . . 107 8.2. Accounting Session State Machine . . . . . . . . . . . . 106
8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 111
8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 111
8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 112
8.4. Session Termination . . . . . . . . . . . . . . . . . . . 114 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 113
8.4.1. Session-Termination-Request . . . . . . . . . . . . 115 8.4.1. Session-Termination-Request . . . . . . . . . . . . 114
8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 115 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 114
8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 116 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 115
8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 117 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 116
8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 117 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 116
8.6. Inferring Session Termination from Origin-State-Id . . . 118 8.6. Inferring Session Termination from Origin-State-Id . . . 117
8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 119 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 118
8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 119 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 118
8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 120 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 119
8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 121 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 120
8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 121 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 120
8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 122 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 121
8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 122 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 121
8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 123 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 122
8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 123 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 122
8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 124 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 123
8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 124 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 123
8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 125 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 124
8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 126 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 125
8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 126 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 125
8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 126 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 125
9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 128 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 128 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 127
9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 129 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 128
9.3. Accounting Application Extension and Requirements . . . . 129 9.3. Accounting Application Extension and Requirements . . . . 128
9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 130 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 129
9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 131 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 130
9.6. Correlation of Accounting Records . . . . . . . . . . . . 131 9.6. Correlation of Accounting Records . . . . . . . . . . . . 130
9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 132 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 131
9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 132 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 131
9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 133 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 132
9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 134 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 133
9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 134 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 133
9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 135 9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 134
9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 136 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 135
9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 136 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 135
9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 136 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 135
9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 136 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 135
9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 137 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 136
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 138 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 137
10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 138 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 137
10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 139 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 138
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 141 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 140
11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 141 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 140
11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 142 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 141
11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 142 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 141
11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 142 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 141
11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 143 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 142
11.3. Application Identifiers . . . . . . . . . . . . . . . . . 143 11.3. Application Identifiers . . . . . . . . . . . . . . . . . 142
11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 143 11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 142
11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 143 11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 143
11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 144 11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 143
11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 144 11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 143
11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 144 11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 143
11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 144 11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 143
11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 144 11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 143
11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 144 11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 143
11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 144 11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 143
11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 145 11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 144
11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 145 11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144
11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 145 11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 144
11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 145 11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 144
11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 145 11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 144
11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 145 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144
12. Diameter protocol related configurable parameters . . . . . . 147 12. Diameter protocol related configurable parameters . . . . . . 146
13. Security Considerations . . . . . . . . . . . . . . . . . . . 148 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147
13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 148 13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147
13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 149 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 148
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
14.1. Normative References . . . . . . . . . . . . . . . . . . 150 14.1. Normative References . . . . . . . . . . . . . . . . . . 149
14.2. Informational References . . . . . . . . . . . . . . . . 152 14.2. Informational References . . . . . . . . . . . . . . . . 151
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 154 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153
Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 155 Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 154
Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 156 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 155
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157
Intellectual Property and Copyright Statements . . . . . . . . . 159 Intellectual Property and Copyright Statements . . . . . . . . . 158
1. Introduction 1. Introduction
Authentication, Authorization and Accounting (AAA) protocols such as Authentication, Authorization and Accounting (AAA) protocols such as
TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
provide dial-up PPP [RFC1661] and terminal server access. Over time, provide dial-up PPP [RFC1661] and terminal server access. Over time,
with the growth of the Internet and the introduction of new access with the growth of the Internet and the introduction of new access
technologies, including wireless, DSL, Mobile IP and Ethernet, technologies, including wireless, DSL, Mobile IP and Ethernet,
routers and network access servers (NAS) have increased in complexity routers and network access servers (NAS) have increased in complexity
and density, putting new demands on AAA protocols. and density, putting new demands on AAA protocols.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
integrity scheme that is required only for use with Response integrity scheme that is required only for use with Response
packets. While [RFC2869] defines an additional authentication and packets. While [RFC2869] defines an additional authentication and
integrity mechanism, use is only required during Extensible integrity mechanism, use is only required during Extensible
Authentication Protocol (EAP) sessions. While attribute-hiding is Authentication Protocol (EAP) sessions. While attribute-hiding is
supported, [RFC2865] does not provide support for per-packet supported, [RFC2865] does not provide support for per-packet
confidentiality. In accounting, [RFC2866] assumes that replay confidentiality. In accounting, [RFC2866] assumes that replay
protection is provided by the backend billing server, rather than protection is provided by the backend billing server, rather than
within the protocol itself. within the protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for While [RFC3162] defines the use of IPsec with RADIUS, support for
IPsec is not required. Since within [RFC2409] authentication IPsec is not required. Since within [RFC4306] authentication
occurs only within Phase 1 prior to the establishment of IPsec SAs occurs only within Phase 1 prior to the establishment of IPsec SAs
in Phase 2, it is typically not possible to define separate trust in Phase 2, it is typically not possible to define separate trust
or authorization schemes for each application. This limits the or authorization schemes for each application. This limits the
usefulness of IPsec in inter-domain AAA applications (such as usefulness of IPsec in inter-domain AAA applications (such as
roaming) where it may be desirable to define a distinct roaming) where it may be desirable to define a distinct
certificate hierarchy for use in a AAA deployment. In order to certificate hierarchy for use in a AAA deployment. In order to
provide universal support for transmission-level security, and provide universal support for transmission-level security, and
enable both intra- and inter-domain AAA deployments, Diameter also enable both intra- and inter-domain AAA deployments, Diameter also
provides support for TLS. Security is discussed in Section 13. provides support for TLS. Security is discussed in Section 13.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
o Creating new authentication/authorization applications o Creating new authentication/authorization applications
o Creating new accounting applications o Creating new accounting applications
o Application authentication procedures o Application authentication procedures
Reuse of existing AVP values, AVPs and Diameter applications are Reuse of existing AVP values, AVPs and Diameter applications are
strongly recommended. Reuse simplifies standardization and strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues. It is implementation and avoids potential interoperability issues. It is
expected that command codes are reused; new command codes can only be expected that command codes are reused; new command codes can only be
created by IETF Consensus (see Section 11.2.1). created by Expert Review (see Section 11.2.1).
1.2.1. Defining New AVP Values 1.2.1. Defining New AVP Values
New applications should attempt to reuse AVPs defined in existing New applications should attempt to reuse AVPs defined in existing
applications when possible, as opposed to creating new AVPs. For applications when possible, as opposed to creating new AVPs. For
AVPs of type Enumerated, an application may require a new value to AVPs of type Enumerated, an application may require a new value to
communicate some service-specific information. communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA In order to allocate a new AVP value, a request MUST be sent to IANA
[RFC2434], along with an explanation of the new AVP value. IANA [RFC2434], along with an explanation of the new AVP value. IANA
skipping to change at page 14, line 22 skipping to change at page 14, line 22
implementation MAY add arbitrary non-mandatory AVPs to any command implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to Section 11.1.1 needing to define a new application. Please refer to Section 11.1.1
for details. for details.
In order to justify allocation of a new application identifier, In order to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code, add new mandatory Diameter applications MUST define one Command Code, add new mandatory
AVPs to the ABNF or significantly change the state machine or AVPs to the ABNF or significantly change the state machine or
processing rules of an existing application. processing rules of an existing application.
The expected AVPs MUST be defined in an ABNF [RFC2234] grammar (see The expected AVPs MUST be defined in an ABNF [RFC4234] grammar (see
Section 3.2). If the Diameter application has accounting Section 3.2). If the Diameter application has accounting
requirements, it MUST also specify the AVPs that are to be present in requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see Section 9.3). However, just the Diameter Accounting messages (see Section 9.3). However, just
because a new authentication application id is required, does not because a new authentication application id is required, does not
imply that a new accounting application id is required. imply that a new accounting application id is required.
When possible, a new Diameter application SHOULD reuse existing When possible, a new Diameter application SHOULD reuse existing
Diameter AVPs, in order to avoid defining multiple AVPs that carry Diameter AVPs, in order to avoid defining multiple AVPs that carry
similar information. similar information.
skipping to change at page 15, line 44 skipping to change at page 15, line 44
machine), then the base protocol defined standard accounting machine), then the base protocol defined standard accounting
application Id (Section 2.4) MUST be used in ACR/ACA commands. application Id (Section 2.4) MUST be used in ACR/ACA commands.
1.2.5. Application Authentication Procedures 1.2.5. Application Authentication Procedures
When possible, applications SHOULD be designed such that new When possible, applications SHOULD be designed such that new
authentication methods MAY be added without requiring changes to the authentication methods MAY be added without requiring changes to the
application. This MAY require that new AVP values be assigned to application. This MAY require that new AVP values be assigned to
represent the new authentication transform, or any other scheme that represent the new authentication transform, or any other scheme that
produces similar results. When possible, authentication frameworks, produces similar results. When possible, authentication frameworks,
such as Extensible Authentication Protocol [RFC2284], SHOULD be used. such as Extensible Authentication Protocol [RFC3748], SHOULD be used.
1.3. Terminology 1.3. Terminology
AAA AAA
Authentication, Authorization and Accounting. Authentication, Authorization and Accounting.
Accounting Accounting
The act of collecting information on resource usage for the The act of collecting information on resource usage for the
purpose of capacity planning, auditing, billing or cost purpose of capacity planning, auditing, billing or cost
skipping to change at page 24, line 28 skipping to change at page 24, line 28
1. For interoperability: All Diameter nodes MUST be prepared to 1. For interoperability: All Diameter nodes MUST be prepared to
receive Diameter messages on any SCTP stream in the association. receive Diameter messages on any SCTP stream in the association.
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the-line streams available to the association to prevent head-of-the-line
blocking. blocking.
2.2. Securing Diameter Messages 2.2. Securing Diameter Messages
Diameter clients, such as Network Access Servers (NASes) and Mobility Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MAY support TLS [RFC2246]. Diameter servers MUST support TLS. Agents MAY support TLS [RFC4346]. Diameter servers MUST support TLS.
IPSec [RFC2401] can be deployed between Diameter peers as an IPSec [RFC4301] can be deployed between Diameter peers as an
additional security measure independent of the Diameter protocol. additional security measure independent of the Diameter protocol.
The Diameter protocol SHOULD NOT be used without any security The Diameter protocol SHOULD NOT be used without any security
mechanism. mechanism.
2.3. Diameter Application Compliance 2.3. Diameter Application Compliance
Application Identifiers are advertised during the capabilities Application Identifiers are advertised during the capabilities
exchange phase (see Section 5.3). For a given application, exchange phase (see Section 5.3). For a given application,
advertising support of an application implies that the sender advertising support of an application implies that the sender
supports all command codes, and the AVPs specified in the associated supports all command codes, and the AVPs specified in the associated
skipping to change at page 39, line 46 skipping to change at page 39, line 46
; The AVP MUST be present and can appear ; The AVP MUST be present and can appear
; anywhere in the message. ; anywhere in the message.
optional = [qual] "[" avp-name "]" optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot ; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included ; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can ; in a fixed or required rule. The AVP can
; appear anywhere in the message. ; appear anywhere in the message.
qual = [min] "*" [max] qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 Section 6.6. ; See ABNF conventions, RFC 4234 Section 6.6.
; The absence of any qualifiers depends on ; The absence of any qualifiers depends on
; whether it precedes a fixed, required, or ; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has ; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST ; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no ; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be ; qualifier, then 0 or 1 such AVP may be
; present. ; present.
; ;
; NOTE: "[" and "]" have a different meaning ; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above). ; than in ABNF (see the optional rule, above).
skipping to change at page 46, line 24 skipping to change at page 46, line 24
format as the definitions below. Each new definition must be either format as the definitions below. Each new definition must be either
defined or listed with a reference to the RFC that defines the defined or listed with a reference to the RFC that defines the
format. format.
The below AVP Derived Data Formats are commonly used by applications. The below AVP Derived Data Formats are commonly used by applications.
Address Address
The Address format is derived from the OctetString AVP Base The Address format is derived from the OctetString AVP Base
Format. It is a discriminated union, representing, for example a Format. It is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [RFC2373] address, most 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [RFC4291] address, most
significant octet first. The first two octets of the Address AVP significant octet first. The first two octets of the Address AVP
represents the AddressType, which contains an Address Family represents the AddressType, which contains an Address Family
defined in [IANAADFAM]. The AddressType is used to discriminate defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets. the content and format of the remaining octets.
Time Time
The Time format is derived from the OctetString AVP Base Format. The Time format is derived from the OctetString AVP Base Format.
The string MUST contain four octets, in the same format as the The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [RFC2030]. Timestamp format is defined in chapter 3 of [RFC4330].
This represents the number of seconds since 0h on 1 January 1900 This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC). with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
SNTP [RFC2030] describes a procedure to extend the time to 2104. SNTP [RFC4330] describes a procedure to extend the time to 2104.
This procedure MUST be supported by all DIAMETER nodes. This procedure MUST be supported by all DIAMETER nodes.
UTF8String UTF8String
The UTF8String format is derived from the OctetString AVP Base The UTF8String format is derived from the OctetString AVP Base
Format. This is a human readable string represented using the Format. This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [RFC2279] transformation format described in RFC 2279. the UTF-8 [RFC3629] transformation format described in RFC 3629.
Since additional code points are added by amendments to the 10646 Since additional code points are added by amendments to the 10646
standard from time to time, implementations MUST be prepared to standard from time to time, implementations MUST be prepared to
encounter any code point from 0x00000001 to 0x7fffffff. Byte encounter any code point from 0x00000001 to 0x7fffffff. Byte
sequences that do not correspond to the valid encoding of a code sequences that do not correspond to the valid encoding of a code
point into UTF-8 charset or are outside this range are prohibited. point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary The use of control codes SHOULD be avoided. When it is necessary
to represent a new line, the control code sequence CR LF SHOULD be to represent a new line, the control code sequence CR LF SHOULD be
used. used.
skipping to change at page 48, line 8 skipping to change at page 48, line 8
The contents of the string MUST be the FQDN of the Diameter node. The contents of the string MUST be the FQDN of the Diameter node.
If multiple Diameter nodes run on the same host, each Diameter If multiple Diameter nodes run on the same host, each Diameter
node MUST be assigned a unique DiameterIdentity. If a Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter
node can be identified by several FQDNs, a single FQDN should be node can be identified by several FQDNs, a single FQDN should be
picked at startup, and used as the only DiameterIdentity for that picked at startup, and used as the only DiameterIdentity for that
node, whatever the connection it is sent on. node, whatever the connection it is sent on.
DiameterURI DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
syntax [RFC2396] rules specified below: syntax [RFC3986] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security ; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used ; Transport security used
FQDN = Fully Qualified Host Name FQDN = Fully Qualified Host Name
skipping to change at page 52, line 29 skipping to change at page 52, line 29
An access device that is unable to interpret or apply a deny rule An access device that is unable to interpret or apply a deny rule
MUST terminate the session. An access device that is unable to MUST terminate the session. An access device that is unable to
interpret or apply a permit rule MAY apply a more restrictive interpret or apply a permit rule MAY apply a more restrictive
rule. An access device MAY apply deny rules of its own before the rule. An access device MAY apply deny rules of its own before the
supplied rules, for example to protect the access device owner's supplied rules, for example to protect the access device owner's
infrastructure. infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
the ipfw.c code may provide a useful base for implementations. the ipfw.c code may provide a useful base for implementations.
QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP Base
Format. It uses the ASCII charset. Packets may be marked or
metered based on the following information that is associated with
it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
DSCP values (no mask or range)
Rules for the appropriate direction are evaluated in order, with
the first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is treated as best
effort. An access device that is unable to interpret or apply a
QoS rule SHOULD NOT terminate the session.
QoSFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
tag - Mark packet with a specific DSCP
[RFC2474]. The DSCP option MUST be
included.
meter - Meter traffic. The metering options
MUST be included.
dir The format is as described under IPFilterRule.
proto The format is as described under
IPFilterRule.
src and dst The format is as described under
IPFilterRule.
4.4. Grouped AVP Values 4.4. Grouped AVP Values
The Diameter protocol allows AVP values of type 'Grouped.' This The Diameter protocol allows AVP values of type 'Grouped.' This
implies that the Data field is actually a sequence of AVPs. It is implies that the Data field is actually a sequence of AVPs. It is
possible to include an AVP with a Grouped type within a Grouped type, possible to include an AVP with a Grouped type within a Grouped type,
that is, to nest them. AVPs within an AVP of type Grouped have the that is, to nest them. AVPs within an AVP of type Grouped have the
same padding requirements as non-Grouped AVPs, as defined in Section same padding requirements as non-Grouped AVPs, as defined in Section
4. 4.
The AVP Code numbering space of all AVPs included in a Grouped AVP is The AVP Code numbering space of all AVPs included in a Grouped AVP is
the same as for non-grouped AVPs. Further, if any of the AVPs the same as for non-grouped AVPs. Further, if any of the AVPs
encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
the Grouped AVP itself MUST also include the 'M' bit set. the Grouped AVP itself MUST also include the 'M' bit set.
Every Grouped AVP defined MUST include a corresponding grammar, using Every Grouped AVP defined MUST include a corresponding grammar, using
ABNF [RFC2234] (with modifications), as defined below. ABNF [RFC4234] (with modifications), as defined below.
grouped-avp-def = name "::=" avp grouped-avp-def = name "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-") name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt name = name-fmt
; The name has to be the name of an AVP, ; The name has to be the name of an AVP,
; defined in the base or extended Diameter ; defined in the base or extended Diameter
; specifications. ; specifications.
skipping to change at page 55, line 50 skipping to change at page 54, line 50
d3427475e49968f841 d3427475e49968f841
The data for the optional AVPs is represented in hex since the format The data for the optional AVPs is represented in hex since the format
of these AVPs is neither known at the time of definition of the of these AVPs is neither known at the time of definition of the
Example-AVP group, nor (likely) at the time when the example instance Example-AVP group, nor (likely) at the time when the example instance
of this AVP is interpreted - except by Diameter implementations which of this AVP is interpreted - except by Diameter implementations which
support the same set of AVPs. The encoding example illustrates how support the same set of AVPs. The encoding example illustrates how
padding is used and how length fields are calculated. Also note that padding is used and how length fields are calculated. Also note that
AVPs may be present in the Grouped AVP value which the receiver AVPs may be present in the Grouped AVP value which the receiver
cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record
AVPs). AVPs). The length of the Example-AVP is the sum of all the length of
the member AVPs including their padding plus the Example-AVP header
size.
This AVP would be encoded as follows: This AVP would be encoded as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 468 | 0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | 32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| 72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
72 | Session-Id AVP Header (AVP Code = 263), Length = 51 | 80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
80 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | 88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
104| '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| 120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
112| Recovery-Policy Header (AVP Code = 8341), Length = 223 | 128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
120| 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | 136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
320| 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| 352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
328| Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| 328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
336| 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
464| 0x41 |Padding|Padding|Padding| 488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
4.5. Diameter Base Protocol AVPs 4.5. Diameter Base Protocol AVPs
The following table describes the Diameter AVPs defined in the base The following table describes the Diameter AVPs defined in the base
protocol, their AVP Code values, types, possible flag values. protocol, their AVP Code values, types, possible flag values.
Due to space constraints, the short form DiamIdent is used to Due to space constraints, the short form DiamIdent is used to
represent DiameterIdentity. represent DiameterIdentity.
+---------------------+ +---------------------+
skipping to change at page 61, line 40 skipping to change at page 60, line 40
registry for NAPTR service name to transport protocol registry for NAPTR service name to transport protocol
mappings. mappings.
These NAPTR records provide a mapping from a domain, to the These NAPTR records provide a mapping from a domain, to the
SRV record for contacting a server with the specific transport SRV record for contacting a server with the specific transport
protocol in the NAPTR services field. The resource record protocol in the NAPTR services field. The resource record
will contain an empty regular expression and a replacement will contain an empty regular expression and a replacement
value, which is the SRV record for that particular transport value, which is the SRV record for that particular transport
protocol. If the server supports multiple transport protocol. If the server supports multiple transport
protocols, there will be multiple NAPTR records, each with a protocols, there will be multiple NAPTR records, each with a
different service value. As per RFC 2915 [RFC2915], the different service value. As per [RFC3403], the client
client discards any records whose services fields are not discards any records whose services fields are not applicable.
applicable. For the purposes of this specification, several For the purposes of this specification, several rules are
rules are defined. defined.
* A client MUST discard any service fields that identify a * A client MUST discard any service fields that identify a
resolution service whose value is not "D2X", for values of X resolution service whose value is not "D2X", for values of X
that indicate transport protocols supported by the client. that indicate transport protocols supported by the client.
The NAPTR processing as described in RFC 2915 will result in The NAPTR processing as described in [RFC3403] will result in
discovery of the most preferred transport protocol of the discovery of the most preferred transport protocol of the
server that is supported by the client, as well as an SRV server that is supported by the client, as well as an SRV
record for the server. record for the server.
The domain suffixes in the NAPTR replacement field SHOULD The domain suffixes in the NAPTR replacement field SHOULD
match the domain of the original query. match the domain of the original query.
3. If no NAPTR records are found, the requester queries for those 3. If no NAPTR records are found, the requester queries for those
address records for the destination address, address records for the destination address,
'_diameter._sctp'.realm or '_diameter._tcp'.realm. Address '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address
skipping to change at page 65, line 28 skipping to change at page 64, line 28
<CEA> ::= < Diameter Header: 257 > <CEA> ::= < Diameter Header: 257 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
1* { Host-IP-Address } 1* { Host-IP-Address }
{ Vendor-Id } { Vendor-Id }
{ Product-Name } { Product-Name }
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] [ Failed-AVP ]
* [ Supported-Vendor-Id ] * [ Supported-Vendor-Id ]
* [ Auth-Application-Id ] * [ Auth-Application-Id ]
* [ Inband-Security-Id ] * [ Inband-Security-Id ]
* [ Acct-Application-Id ] * [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ] * [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ] [ Firmware-Revision ]
* [ AVP ] * [ AVP ]
5.3.3. Vendor-Id AVP 5.3.3. Vendor-Id AVP
skipping to change at page 67, line 48 skipping to change at page 66, line 48
to the Disconnect-Peer-Request message. Upon receipt of this to the Disconnect-Peer-Request message. Upon receipt of this
message, the transport connection is shutdown. message, the transport connection is shutdown.
Message Format Message Format
<DPA> ::= < Diameter Header: 282 > <DPA> ::= < Diameter Header: 282 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] [ Failed-AVP ]
5.4.3. Disconnect-Cause AVP 5.4.3. Disconnect-Cause AVP
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST include this AVP in the Disconnect-Peer-Request Diameter node MUST include this AVP in the Disconnect-Peer-Request
message to inform the peer of the reason for its intention to message to inform the peer of the reason for its intention to
shutdown the transport connection. The following values are shutdown the transport connection. The following values are
supported: supported:
REBOOTING 0 REBOOTING 0
skipping to change at page 69, line 18 skipping to change at page 68, line 18
to 280 and the Command Flags' 'R' bit cleared, is sent as a response to 280 and the Command Flags' 'R' bit cleared, is sent as a response
to the Device-Watchdog-Request message. to the Device-Watchdog-Request message.
Message Format Message Format
<DWA> ::= < Diameter Header: 280 > <DWA> ::= < Diameter Header: 280 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] [ Failed-AVP ]
[ Origin-State-Id ] [ Origin-State-Id ]
5.5.3. Transport Failure Algorithm 5.5.3. Transport Failure Algorithm
The transport failure algorithm is defined in [RFC3539]. All The transport failure algorithm is defined in [RFC3539]. All
Diameter implementations MUST support the algorithm defined in the Diameter implementations MUST support the algorithm defined in the
specification in order to be compliant to the Diameter base protocol. specification in order to be compliant to the Diameter base protocol.
5.5.4. Failover and Failback Procedures 5.5.4. Failover and Failback Procedures
skipping to change at page 86, line 44 skipping to change at page 85, line 44
Currently, the following values are supported, but there is ample Currently, the following values are supported, but there is ample
room to add new security Ids. room to add new security Ids.
NO_INBAND_SECURITY 0 NO_INBAND_SECURITY 0
This peer does not support TLS. This is the default value, if the This peer does not support TLS. This is the default value, if the
AVP is omitted. AVP is omitted.
TLS 1 TLS 1
This node supports TLS security, as defined by [RFC2246]. This node supports TLS security, as defined by [RFC4346].
6.11. Vendor-Specific-Application-Id AVP 6.11. Vendor-Specific-Application-Id AVP
The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
Grouped and is used to advertise support of a vendor-specific Grouped and is used to advertise support of a vendor-specific
Diameter Application. Exactly one instance of Auth-Application-Id or Diameter Application. Exactly one instance of Auth-Application-Id or
Acct-Application-Id AVP MAY be present. The application identifier Acct-Application-Id AVP MAY be present. The application identifier
carried by either Auth-Application-Id or Acct-Application-Id AVP MUST carried by either Auth-Application-Id or Acct-Application-Id AVP MUST
comply with vendor specific application identifier assignment comply with vendor specific application identifier assignment
described in Sec 11.3. It MUST also match the application id present described in Sec 11.3. It MUST also match the application id present
skipping to change at page 96, line 19 skipping to change at page 95, line 19
A request was received that cannot be authorized because the user A request was received that cannot be authorized because the user
has already expended allowed resources. An example of this error has already expended allowed resources. An example of this error
condition is a user that is restricted to one dial-up PPP port, condition is a user that is restricted to one dial-up PPP port,
attempts to establish a second PPP connection. attempts to establish a second PPP connection.
DIAMETER_CONTRADICTING_AVPS 5007 DIAMETER_CONTRADICTING_AVPS 5007
The Home Diameter server has detected AVPs in the request that The Home Diameter server has detected AVPs in the request that
contradicted each other, and is not willing to provide service to contradicted each other, and is not willing to provide service to
the user. One or more Failed-AVP AVPs MUST be present, containing the user. The Failed-AVP AVPs MUST be present which contains the
the AVPs that contradicted each other. AVPs that contradicted each other.
DIAMETER_AVP_NOT_ALLOWED 5008 DIAMETER_AVP_NOT_ALLOWED 5008
A message was received with an AVP that MUST NOT be present. The A message was received with an AVP that MUST NOT be present. The
Failed-AVP AVP MUST be included and contain a copy of the Failed-AVP AVP MUST be included and contain a copy of the
offending AVP. offending AVP.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message was received that included an AVP that appeared more A message was received that included an AVP that appeared more
skipping to change at page 99, line 28 skipping to change at page 98, line 28
A Diameter message SHOULD contain one Failed-AVP AVP, containing the A Diameter message SHOULD contain one Failed-AVP AVP, containing the
entire AVP that could not be processed successfully. If the failure entire AVP that could not be processed successfully. If the failure
reason is omission of a required AVP, an AVP with the missing AVP reason is omission of a required AVP, an AVP with the missing AVP
code, the missing vendor id, and a zero filled payload of the minimum code, the missing vendor id, and a zero filled payload of the minimum
required length for the omitted AVP will be added. If the failure required length for the omitted AVP will be added. If the failure
reason is an invalid AVP length where the reported length is less reason is an invalid AVP length where the reported length is less
than the minimum AVP header length or greater than the reported than the minimum AVP header length or greater than the reported
message length, a copy of the offending AVP header and a zero filled message length, a copy of the offending AVP header and a zero filled
payload of the minimum required length SHOULD be added. payload of the minimum required length SHOULD be added.
In the case where the offending AVP is embedded within a grouped AVP,
the Failed-AVP MAY contain the grouped AVP which in turn contains the
single offending AVP. The same method MAY be employed if the grouped
AVP itself is embedded in yet another grouped AVP and so on. In this
case, the Failed-AVP MAY contain the grouped AVP heirarchy up to the
single offending AVP. This enables the recipient to detect the
location of the offending AVP when embedded in a group.
AVP Format AVP Format
<Failed-AVP> ::= < AVP Header: 279 > <Failed-AVP> ::= < AVP Header: 279 >
1* {AVP} 1* {AVP}
7.6. Experimental-Result AVP 7.6. Experimental-Result AVP
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
indicates whether a particular vendor-specific request was completed indicates whether a particular vendor-specific request was completed
successfully or whether an error occurred. Its Data field has the successfully or whether an error occurred. Its Data field has the
skipping to change at page 113, line 42 skipping to change at page 112, line 42
<RAA> ::= < Diameter Header: 258, PXY > <RAA> ::= < Diameter Header: 258, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] [ Failed-AVP ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Host-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
8.4. Session Termination 8.4. Session Termination
It is necessary for a Diameter server that authorized a session, for It is necessary for a Diameter server that authorized a session, for
which it is maintaining state, to be notified when that session is no which it is maintaining state, to be notified when that session is no
longer active, both for tracking purposes as well as to allow longer active, both for tracking purposes as well as to allow
stateful agents to release any resources that they may have provided stateful agents to release any resources that they may have provided
for the user's session. For sessions whose state is not being for the user's session. For sessions whose state is not being
skipping to change at page 116, line 16 skipping to change at page 115, line 16
<STA> ::= < Diameter Header: 275, PXY > <STA> ::= < Diameter Header: 275, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ] [ User-Name ]
* [ Class ] * [ Class ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] [ Failed-AVP ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
^ ^
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
8.5. Aborting a Session 8.5. Aborting a Session
skipping to change at page 118, line 16 skipping to change at page 117, line 16
<ASA> ::= < Diameter Header: 274, PXY > <ASA> ::= < Diameter Header: 274, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] [ Failed-AVP ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
8.6. Inferring Session Termination from Origin-State-Id 8.6. Inferring Session Termination from Origin-State-Id
Origin-State-Id is used to allow rapid detection of terminated Origin-State-Id is used to allow rapid detection of terminated
sessions for which no STR would have been issued, due to sessions for which no STR would have been issued, due to
skipping to change at page 129, line 21 skipping to change at page 128, line 21
AAA server, which MUST reply with the Accounting-Answer message to AAA server, which MUST reply with the Accounting-Answer message to
confirm reception. The Accounting-Answer message includes the confirm reception. The Accounting-Answer message includes the
Result-Code AVP, which MAY indicate that an error was present in the Result-Code AVP, which MAY indicate that an error was present in the
accounting message. A rejected Accounting-Request message MAY cause accounting message. A rejected Accounting-Request message MAY cause
the user's session to be terminated, depending on the value of the the user's session to be terminated, depending on the value of the
Accounting-Realtime-Required AVP received earlier for the session in Accounting-Realtime-Required AVP received earlier for the session in
question. question.
Each Diameter Accounting protocol message MAY be compressed, in order Each Diameter Accounting protocol message MAY be compressed, in order
to reduce network bandwidth usage. If TLS is used to secure the to reduce network bandwidth usage. If TLS is used to secure the
Diameter session, then TLS compression [RFC2246] MAY be used. Diameter session, then TLS compression [RFC4346] MAY be used.
9.3. Accounting Application Extension and Requirements 9.3. Accounting Application Extension and Requirements
Each Diameter application (e.g., NASREQ, MobileIP), MUST define their Each Diameter application (e.g., NASREQ, MobileIP), MUST define their
Service-Specific AVPs that MUST be present in the Accounting-Request Service-Specific AVPs that MUST be present in the Accounting-Request
message in a section entitled "Accounting AVPs". The application message in a section entitled "Accounting AVPs". The application
MUST assume that the AVPs described in this document will be present MUST assume that the AVPs described in this document will be present
in all Accounting messages, so only their respective service-specific in all Accounting messages, so only their respective service-specific
AVPs need to be defined in this section. AVPs need to be defined in this section.
skipping to change at page 133, line 21 skipping to change at page 132, line 21
<ACR> ::= < Diameter Header: 271, REQ, PXY > <ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Accounting-Record-Type } { Accounting-Record-Type }
{ Accounting-Record-Number } { Accounting-Record-Number }
[ Acct-Application-Id ] [ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ] [ Vendor-Specific-Application-Id ]
[ User-Name ] [ User-Name ]
[ Destination-Host ]
[ Accounting-Sub-Session-Id ] [ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ] [ Acct-Session-Id ]
[ Acct-Multi-Session-Id ] [ Acct-Multi-Session-Id ]
[ Acct-Interim-Interval ] [ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ] [ Accounting-Realtime-Required ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Event-Timestamp ] [ Event-Timestamp ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
skipping to change at page 138, line 8 skipping to change at page 137, line 8
GRANT_AND_LOSE 3 GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means that service The AVP with Value field set to GRANT_AND_LOSE means that service
SHOULD be granted even if the records can not be delivered or SHOULD be granted even if the records can not be delivered or
stored. stored.
10. AVP Occurrence Table 10. AVP Occurrence Table
The following tables presents the AVPs defined in this document, and The following tables presents the AVPs defined in this document, and
specifies in which Diameter messages they MAY, or MAY NOT be present. specifies in which Diameter messages they MAY be present or not.
Note that AVPs that can only be present within a Grouped AVP are not Note that AVPs that can only be present within a Grouped AVP are not
represented in this table. represented in this table.
The table uses the following symbols: The table uses the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the 0+ Zero or more instances of the AVP MAY be present in the
message. message.
skipping to change at page 140, line 31 skipping to change at page 139, line 31
Destination-Host | 0-1 | 0 | Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 | Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ | Error-Reporting-Host | 0 | 0+ |
Event-Timestamp | 0-1 | 0-1 | Event-Timestamp | 0-1 | 0-1 |
Origin-Host | 1 | 1 | Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 | Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ | Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0+ | Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 | Result-Code | 0 | 1 |
Session-Id | 1 | 1 | Session-Id | 1 | 1 |
Termination-Cause | 0-1 | 0-1 | Termination-Cause | 0 | 0 |
User-Name | 0-1 | 0-1 | User-Name | 0-1 | 0-1 |
Vendor-Specific-Application-Id| 0-1 | 0-1 | Vendor-Specific-Application-Id| 0-1 | 0-1 |
------------------------------+-----+-----+ ------------------------------+-----+-----+
11. IANA Considerations 11. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
Diameter protocol, in accordance with BCP 26 [RFC2434]. The Diameter protocol, in accordance with BCP 26 [RFC2434]. The
following policies are used here with the meanings defined in BCP 26: following policies are used here with the meanings defined in BCP 26:
skipping to change at page 141, line 24 skipping to change at page 140, line 24
This section explains the criteria to be used by the IANA for This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces defined within this document. assignment of numbers within namespaces defined within this document.
Diameter is not intended as a general purpose protocol, and Diameter is not intended as a general purpose protocol, and
allocations SHOULD NOT be made for purposes unrelated to allocations SHOULD NOT be made for purposes unrelated to
authentication, authorization or accounting. authentication, authorization or accounting.
For registration requests where a Designated Expert should be For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the consulted, the responsible IESG area director should appoint the
Designated Expert. For Designated Expert with Specification Designated Expert. For Designated Expert with Specification
Required, the request is posted to the AAA WG mailing list (or, if it Required, the request is posted to the DIME WG mailing list (or, if
has been disbanded, a successor designated by the Area Director) for it has been disbanded, a successor designated by the Area Director)
comment and review, and MUST include a pointer to a public for comment and review, and MUST include a pointer to a public
specification. Before a period of 30 days has passed, the Designated specification. Before a period of 30 days has passed, the Designated
Expert will either approve or deny the registration request and Expert will either approve or deny the registration request and
publish a notice of the decision to the AAA WG mailing list or its publish a notice of the decision to the DIME WG mailing list or its
successor. A denial notice must be justified by an explanation and, successor. A denial notice must be justified by an explanation and,
in the cases where it is possible, concrete suggestions on how the in the cases where it is possible, concrete suggestions on how the
request can be modified so as to become acceptable. request can be modified so as to become acceptable.
11.1. AVP Header 11.1. AVP Header
As defined in Section 4, the AVP header contains three fields that As defined in Section 4, the AVP header contains three fields that
requires IANA namespace management; the AVP Code, Vendor-ID and Flags requires IANA namespace management; the AVP Code, Vendor-ID and Flags
field. field.
skipping to change at page 142, line 38 skipping to change at page 141, line 38
11.2. Diameter Header 11.2. Diameter Header
As defined in Section 3, the Diameter header contains two fields that As defined in Section 3, the Diameter header contains two fields that
require IANA namespace management; Command Code and Command Flags. require IANA namespace management; Command Code and Command Flags.
11.2.1. Command Codes 11.2.1. Command Codes
The Command Code namespace is used to identify Diameter commands. The Command Code namespace is used to identify Diameter commands.
The values 0-255 are reserved for RADIUS backward compatibility, and The values 0-255 are reserved for RADIUS backward compatibility, and
are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256- are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256-
16,777,213 are for permanent, standard commands, allocated by IETF 16,777,213 are for permanent, standard commands, allocated by Expert
Consensus [RFC2434]. This document defines the Command Codes 257, Review [RFC2434]. This document defines the Command Codes 257, 258,
258, 271, 274-275, 280 and 282. See Section 3.1 for the assignment 271, 274-275, 280 and 282. See Section 3.1 for the assignment of the
of the namespace in this specification. namespace in this specification.
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
0xffffff) are reserved for experimental commands. As these codes are 0xffffff) are reserved for experimental commands. As these codes are
only for experimental and testing purposes, no guarantee is made for only for experimental and testing purposes, no guarantee is made for
interoperability between Diameter peers using experimental commands, interoperability between Diameter peers using experimental commands,
as outlined in [IANA-EXP]. as outlined in [IANA-EXP].
[Editor's note: The expert review process for command code allocation
is being introduced to hasten the allocation process itself.
Hopefully this will lessen the tendency to circumvent this process.
Details will be added in subsequent revisions and more complete
description will be added in the design guidelines document.]
11.2.2. Command Flags 11.2.2. Command Flags
There are eight bits in the Command Flags field of the Diameter There are eight bits in the Command Flags field of the Diameter
header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy), header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy),
bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be
assigned via a Standards Action [RFC2434]. assigned via a Standards Action [RFC2434].
11.3. Application Identifiers 11.3. Application Identifiers
As defined in Section 2.4, the Application Identifier is used to As defined in Section 2.4, the Application Identifier is used to
skipping to change at page 148, line 15 skipping to change at page 147, line 15
13. Security Considerations 13. Security Considerations
The Diameter base protocol assumes that messages maybe secured by The Diameter base protocol assumes that messages maybe secured by
using TLS. As an alternative, IPSec can be also be used to secure using TLS. As an alternative, IPSec can be also be used to secure
Diameter peer connections but its usage is transparent from the Diameter peer connections but its usage is transparent from the
Diameter node and Diameter protocol perspective. These security Diameter node and Diameter protocol perspective. These security
mechanism is acceptable in environments where there is no untrusted mechanism is acceptable in environments where there is no untrusted
third party agent. third party agent.
Diameter clients, such as Network Access Servers (NASes) and Mobility Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MAY support TLS [RFC2246]. Diameter servers MUST support TLS. Agents MAY support TLS [RFC4346]. Diameter servers MUST support TLS.
Diameter implementations SHOULD use transmission-level security of Diameter implementations SHOULD use transmission-level security of
some kind (IPsec or TLS) on each connection. some kind (IPsec or TLS) on each connection.
If a Diameter connection is to be protected via TLS, then the CER/CEA If a Diameter connection is to be protected via TLS, then the CER/CEA
exchange MUST include an Inband-Security-ID AVP with a value of TLS. exchange MUST include an Inband-Security-ID AVP with a value of TLS.
For TLS usage, a TLS handshake will begin when both ends are in the For TLS usage, a TLS handshake will begin when both ends are in the
open state, after completion of the CER/CEA exchange. If the TLS open state, after completion of the CER/CEA exchange. If the TLS
handshake is successful, all further messages will be sent via TLS. handshake is successful, all further messages will be sent via TLS.
If the handshake fails, both ends move to the closed state. See If the handshake fails, both ends move to the closed state. See
Sections 13.1 for more details. Sections 13.1 for more details.
13.1. TLS Usage 13.1. TLS Usage
A Diameter node that initiates a connection to another Diameter node A Diameter node that initiates a connection to another Diameter node
acts as a TLS client according to [RFC2246], and a Diameter node that acts as a TLS client according to [RFC4346], and a Diameter node that
accepts a connection acts as a TLS server. Diameter nodes accepts a connection acts as a TLS server. Diameter nodes
implementing TLS for security MUST mutually authenticate as part of implementing TLS for security MUST mutually authenticate as part of
TLS session establishment. In order to ensure mutual authentication, TLS session establishment. In order to ensure mutual authentication,
the Diameter node acting as TLS server must request a certificate the Diameter node acting as TLS server must request a certificate
from the Diameter node acting as TLS client, and the Diameter node from the Diameter node acting as TLS client, and the Diameter node
acting as TLS client MUST be prepared to supply a certificate on acting as TLS client MUST be prepared to supply a certificate on
request. request.
Diameter nodes MUST be able to negotiate the following TLS cipher Diameter nodes MUST be able to negotiate the following TLS cipher
suites: suites:
skipping to change at page 150, line 50 skipping to change at page 149, line 50
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C., and K. Tammi, "Diameter Session Canales-Valenzuela, C., and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application", RFC 4740, Initiation Protocol (SIP) Application", RFC 4740,
November 2006. November 2006.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
"Definition of the Differentiated Services Field (DS Levkowetz, "Extensible Authentication Protocol (EAP)",
Field) in the IPv4 and IPv6 Headers", RFC 2474, RFC 3748, June 2004.
December 1998.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
(IKE)", RFC 2409, November 1998. RFC 4306, December 2005.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 4291, February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
(NAPTR) DNS Resource Record", RFC 2915, September 2000. Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
for IPv4, IPv6 and OSI", RFC 2030, October 1996. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", STD 66,
August 1998. RFC 3986, January 2005.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", STD 63, RFC 3629, November 2003.
14.2. Informational References 14.2. Informational References
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil, Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen, D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim, S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques, B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
"Criteria for Evaluating AAA Protocols for Network "Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000. Access", RFC 2989, November 2000.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000. Accounting Management", RFC 2975, October 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576, Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003. July 2003.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
skipping to change at page 153, line 6 skipping to change at page 151, line 51
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194, "Review of Roaming Implementations", RFC 2194,
September 1997. September 1997.
[RFC2477] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming [RFC2477] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999. Protocols", RFC 2477, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 4301, December 2005.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993. TACACS", RFC 1492, July 1993.
[IANA-EXP] [IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful, Work in Progress.". Considered Useful, Work in Progress.".
Appendix A. Acknowledgements Appendix A. Acknowledgements
skipping to change at page 158, line 26 skipping to change at page 157, line 26
Jari Arkko Jari Arkko
Ericsson Research Ericsson Research
02420 Jorvas 02420 Jorvas
Finland Finland
Phone: +358 40 5079256 Phone: +358 40 5079256
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
John Loughney John Loughney
Nokia Research Center Nokia Research Center
Itamerenkatu 11-13 955 Page Mill Road
Helsinki, 00180 Palo Alto, CA 94304
Finland US
Phone: +358 50 483 6242 Phone: 1-650-283-8068
Email: john.loughney@nokia.com Email: john.loughney@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 67 change blocks. 
285 lines changed or deleted 265 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/