idnits 2.17.1 draft-jones-dime-extended-naptr-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.ii 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3588, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (August 23, 2009) is 5358 days in the past. Is this intentional? 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Jones 3 Internet-Draft Bridgewater Systems 4 Updates: 3588 (if approved) J. Korhonen 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: February 24, 2010 August 23, 2009 8 Diameter Extended NAPTR 9 draft-jones-dime-extended-naptr-00 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 February 24, 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 describes an extended format for the NAPTR service 58 fields used in dynamic Diameter agent discovery. The extended format 59 allows NAPTR queries contain Diameter Application-Id information. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Extended NAPTR Service Field . . . . . . . . . . . . . . . . . 4 72 4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 The Diameter base protocol [RFC3588] specifies three mechanisms for 81 the Diameter peer discovery. One of these involves the Diameter 82 implementation performing a NAPTR query [RFC3403] for a server in a 83 particular realm. These NAPTR records provide a mapping from a 84 domain, to the SRV record [RFC2782] for contacting a server with the 85 specific transport protocol in the NAPTR services field. 87 Section 11.6 of RFC 3588 defines the following NAPTR service fields: 89 Services Field Protocol 90 AAA+D2T TCP 91 AAA+D2S SCTP 93 However, foreseen network topologies require border AAA nodes that 94 will be specialized by Diameter application and the NAPTR service 95 field does not allow a Diameter implementation to determine the 96 application supported by the AAA node. Without this information, a 97 Diameter implementation must connect and perform a capability 98 negotiation with each candidate AAA node. This document addresses 99 this problem by specifying an extended NAPTR service field format 100 that permits discovery of Diameter peers that support a specific 101 Diameter application. 103 2. Terminology 105 The Diameter base protocol specification (Section 1.4 of RFC 3588) 106 defines most of the terminology used in this document. 108 3. Extended NAPTR Service Field 110 The Extended NAPTR service field ABNF specification for the discovery 111 of Diameter agents supporting a specific Diameter application is show 112 below. 114 naptr-svc-field = "AAA+D2" < protocol> [ *appln-list ] 116 protocol = "T" / "S" 117 ; "T" for TCP and "S" for SCTP. 119 appln-list = "+AP:" appln-id [ *( "," appln-id ) ] 120 ; Comma separated list of application 121 ; identifiers prefixed by "+AP:". 123 appln-id = *DIGIT 124 ; Application identifier expressed as a 125 ; decimal integer. 127 For example, a NAPTR service field value of: 129 'AAA+D2S+AP:6' 131 Means that the Diameter node in the SRV record supports the 132 Diameter Session Initiation Protocol (SIP) Application ('6') and 133 SCTP as the transport protocol. 135 'AAA+D2S+AP:6,1,5,4294967295' 137 Means that the Diameter node in the SRV record supports the 138 Diameter Session Initiation Protocol (SIP) Application ('6'), 139 NASREQ Application ('1'), EAP Application ('5') and SCTP as the 140 transport protocol. The Diameter node also provides Relay 141 functionality ('4294967295'). 143 The maximum length of the NAPTR service field is 256 octets including 144 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 145 of [RFC1035]). The DNS administrator of some domain SHOULD also 146 provision base RFC 3588 style NAPTR records in order to guarantee 147 backwards compatibility with legacy RFC 3588 compliant Diameter 148 peers. 150 4. Extended NAPTR-based Diameter Peer Discovery 152 The basic Diameter Peer Discover principles are described in Section 153 5.2 of RFC 3588. This specification extends the step 3. Diameter 154 peer discovery mechanism by allowing the querying node examine which 155 applications are supported by resolved Diameter peers. The 156 assumption for this mechanism to work is that the DNS administrator 157 of the queried domain has provisioned the DNS with extended NAPTRs in 158 the first place. The text below is slightly modified from RFC 3588. 160 1. ... 162 2. ... 164 3. The Diameter implementation performs a NAPTR query for a server in 165 a particular realm. The Diameter implementation has to know in 166 advance which realm to look for a Diameter agent in and which 167 Application Identifier it is interested in. The realm could be 168 deduced, for example, from the 'realm' in a NAI that a Diameter 169 implementation needed to perform a Diameter operation on. 171 3.1 The services relevant for the task of transport protocol 172 selection are those with NAPTR service fields with values "AAA+ 173 D2x+AP:y", where 'x' is a letter that corresponds to a 174 transport protocol supported by the domain and 'y' is one or 175 more Application Identifiers. 176 ... 178 3.2 A client MUST discard any service fields that identify a 179 resolution service whose value is not "D2X", for values of X 180 that indicate transport protocols supported by the client. The 181 client SHOULD also discard any service fields that do not 182 identify support for the application the client is looking for 183 i.e. the desired Application Identifier is not listed in 184 'AP:y'. 185 ... 187 5. IANA Considerations 189 Editor's Note: Verify impacts to IANA registries. 191 6. Security Considerations 193 This document specifies an enhancement to the NAPTR service field 194 format defined in the Diameter base protocol and the same security 195 considerations described in RFC 3588 are applicable to this document. 196 No further extensions are required beyond the security mechanisms 197 offered by RFC 3588. 199 7. Normative References 201 [RFC1035] Mockapetris, P., "Domain names - implementation and 202 specification", STD 13, RFC 1035, November 1987. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 208 specifying the location of services (DNS SRV)", RFC 2782, 209 February 2000. 211 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 212 Part Three: The Domain Name System (DNS) Database", 213 RFC 3403, October 2002. 215 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 216 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 218 Authors' Addresses 220 Mark Jones 221 Bridgewater Systems 223 Email: mark.jones@bridgewatersystems.com 225 Jouni Korhonen 226 Nokia Siemens Networks 228 Email: jouni.nospam@gmail.com