idnits 2.17.1 draft-ietf-dime-capablities-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2009) is 5359 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track K. Jiao 5 Expires: January 28, 2010 Huawei Technologies 6 July 27, 2009 8 The Diameter Capabilities Update Application 9 draft-ietf-dime-capablities-update-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 28, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document defines a new Diameter application and associated 58 command codes. The Capabilities Update application is intended to 59 allow the dynamic update of Diameter peer capabilities while the 60 peer-to-peer connection is in the open state. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 66 3. Diameter Protocol Considerations . . . . . . . . . . . . . . . 3 67 4. Capabilities Update . . . . . . . . . . . . . . . . . . . . . . 3 68 4.1. Command-Code Values . . . . . . . . . . . . . . . . . . . . 4 69 4.1.1. Capabilities-Update-Request . . . . . . . . . . . . . . 5 70 4.1.2. Capabilities-Update-Answer . . . . . . . . . . . . . . 5 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Application Identifier . . . . . . . . . . . . . . . . . . 6 73 5.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 Capabilities exchange is an important component of the Diameter Base 83 Protocol [RFC3588], allowing peers to exchange identities and 84 Diameter capabilities (protocol version number, supported Diameter 85 applications, security mechanisms, etc.). As defined in RFC 3588, 86 however, the capabilities exchange process takes place only once, at 87 the inception of a transport connection between a given pair of 88 peers. Therefore, if a peer's capabilities change (due to software 89 update, for example), the existing connection(s) must be torn down 90 (along with all of the associated user sessions) and restarted before 91 the modified capabilities can be advertised. 93 This document defines a new Diameter application intended to allow 94 the dynamic update of Diameter peer capabilities over an existing 95 connection. Because the Capabilities Update application specified 96 here operates over an existing transport connection, modification of 97 the security mechanism in use is not allowed; if the security method 98 used between a pair of peers is changed the affected connection MUST 99 be restarted. 101 Discussion of this draft may be directed to the authors. 103 2. Specification of Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Diameter Protocol Considerations 111 This section details the relationship of the Diameter Capabilities 112 Update application to the Diameter Base Protocol. 114 This document specifies Diameter Application-ID . Diameter 115 nodes conforming to this specification MAY advertise support by 116 including the value of in the Auth-Application-Id of the 117 Capabilities-Exchange-Req and Capabilities-Exchange-Answer commands 118 [RFC3588]. 120 4. Capabilities Update 122 When the capabilities of a Diameter node conforming to this 123 specification change, it SHOULD notify all of the nodes with which it 124 has an open transport connection using the Capabilities-Update-Req 125 message (Section 4.1.1). This message allows the update of a peer's 126 identity and its capabilities (protocol version number, supported 127 Diameter applications, etc.). 129 The receiver only issues commands to its peers that have advertised 130 support for the Diameter application that defines the command. A 131 Diameter node MUST cache the supported applications in order to 132 ensure that unrecognized commands and/or AVPs are not unnecessarily 133 sent to a peer. 135 The receiver of the Capabilities-Update-Request (CUR) MUST determine 136 common applications by computing the intersection of its own set of 137 supported Application Id against all of the application identifier 138 AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- 139 Application-Id) present in the CUR. The value of the Vendor-Id AVP 140 in the Vendor-Specific-Application-Id MUST NOT be used during 141 computation. 143 If the receiver of a Capabilities-Update-Req (CUR) message does not 144 have any applications in common with the sender then it MUST return a 145 Capabilities-Update-Answer (CUA) with the Result-Code AVP set to 146 DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport 147 layer connection; however, if active sessions are using the 148 connection, peers MAY delay disconnection until the sessions can be 149 redirected or gracefully terminated. Note that receiving a CUR or 150 CUA from a peer advertising itself as a Relay (see [RFC3588], Section 151 2.4) MUST be interpreted as having common applications with the peer. 153 The CUR and CUA messages MUST NOT be proxied, redirected or relayed. 155 Since the CUR/CUA messages cannot be proxied, it is still possible 156 that an upstream agent receives a message for which it has no 157 available peers to handle the application that corresponds to the 158 Command-Code. In such instances, the 'E' bit is set in the answer 159 message with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to 160 inform the downstream peer to take action (e.g., re-routing requests 161 to an alternate peer). 163 4.1. Command-Code Values 165 This section defines Command-Code [RFC3588] values that MUST be 166 supported by all Diameter implementations conforming to this 167 specification. The following Command Codes are defined in this 168 document: Capabilities-Update-Request (CUR)Section 4.1.1 and 169 Capabilities-Update-Answer (CUA) Section 4.1.2. 171 4.1.1. Capabilities-Update-Request 173 The Capabilities-Update-Request (CUR), indicated by the Command-Code 174 set to and the Command Flags' 'R' bit set, is sent to update 175 local capabilities. Upon detection of a transport failure, this 176 message MUST NOT be sent to an alternate peer. 178 When Diameter is run over SCTP [RFC2960], which allows connections to 179 span multiple interfaces and multiple IP addresses, the Capabilities- 180 Update-Request message MUST contain one Host-IP-Address AVP for each 181 potential IP address that may be locally used when transmitting 182 Diameter messages. 184 Message Format 186 ::= < Diameter Header: TBD2, REQ > 187 { Origin-Host } 188 { Origin-Realm } 189 1* { Host-IP-Address } 190 { Vendor-Id } 191 { Product-Name } 192 [ Origin-State-Id ] 193 * [ Supported-Vendor-Id ] 194 * [ Auth-Application-Id ] 195 * [ Acct-Application-Id ] 196 * [ Vendor-Specific-Application-Id ] 197 [ Firmware-Revision ] 198 * [ AVP ] 200 4.1.2. Capabilities-Update-Answer 202 The Capabilities-Update-Answer indicated by the Command-Code set to 203 and the Command Flags' 'R' bit set, is sent in response to a 204 CUR message. 206 Message Format 208 ::= < Diameter Header: TBD3 > 209 { Origin-Host } 210 { Origin-Realm } 211 { Result-Code } 212 [ Error-Message ] 213 * [ AVP ] 215 5. IANA Considerations 217 This section explains the criteria to be used by the IANA for 218 assignment of numbers within namespaces used within this document. 220 5.1. Application Identifier 222 This specification assigns the value from the Application 223 Identifiers namespace defined in RFC 3588. See section Section 3 for 224 the assignment of the namespace in this specification. 226 5.2. Command Codes 228 This specification assigns the values and from the 229 Command Codes namespace defined in RFC 3588. See section Section 4.1 230 for the assignment of the namespace in this specification. 232 6. Security Considerations 234 This document does not introduce any new vulnerabilities into the 235 Diameter protocol. 237 7. References 239 7.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 245 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 247 7.2. Informative References 249 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 250 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 251 Zhang, L., and V. Paxson, "Stream Control Transmission 252 Protocol", RFC 2960, October 2000. 254 Authors' Addresses 256 Glen Zorn 257 Network Zen 258 1310 East Thomas Street 259 #306 260 Seattle, Washington 98102 261 USA 263 Phone: +1 (206) 377-9035 264 Email: gwz@net-zen.net 266 Jiao Kang 267 Huawei Technologies 268 Section B1, Huawei Industrial Base 269 Bantian, Longgang District 270 Shenzhen 518129 271 P.R. China 273 Phone: +86 755 28786690 274 Email: kangjiao@huawei.com