| 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/ | ||||