idnits 2.17.1 draft-ietf-dime-extended-naptr-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 311 has weird spacing: '...service rege...' == Line 335 has weird spacing: '...service rege...' (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 3, 2011) is 4640 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) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiMAX' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions M. Jones 3 (DIME) Bridgewater Systems 4 Internet-Draft J. Korhonen 5 Updates: 3588 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track L. Morand 7 Expires: February 4, 2012 Orange Labs 8 August 3, 2011 10 Diameter S-NAPTR Usage 11 draft-ietf-dime-extended-naptr-09 13 Abstract 15 The Diameter base protocol specifies mechanisms whereby a given realm 16 may advertise Diameter nodes and the supported transport protocol. 17 However, these mechanisms do not reveal the Diameter applications 18 that each node supports. A peer outside the realm would have to 19 perform a Diameter capability exchange with every node until it 20 discovers one that supports the required application. This document 21 updates RFC3588 "Diameter Base Protocol" and describes an improvement 22 using an extended format for the Straightforward-Naming Authority 23 Pointer (S-NAPTR) Application Service Tag that allows for discovery 24 of the supported applications without doing Diameter capability 25 exchange beforehand. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 4, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3 70 3.1. IETF Standard Track Diameter Applications . . . . . . . . 4 71 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 5 72 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 73 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 74 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 8 78 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 9 79 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 9 80 7.4. Vendor-Specific Diameter Application Service Tags . . . . 10 81 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 11 85 11. Normative References . . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 The Diameter base protocol [RFC3588] specifies three mechanisms for 91 the Diameter peer discovery. One of these involves the Diameter 92 implementation performing a Naming Authority Pointer (NAPTR) query 93 [RFC3403] for a server in a particular realm. These NAPTR records 94 provide a mapping from a domain, to the DNS Service Locator (SRV) 95 record [RFC2782] or A/AAAA record [RFC1035][RFC3596] for contacting a 96 server with the specific transport protocol in the NAPTR services 97 field. 99 The extended NAPTR usage for Diameter peer discovery defined by this 100 document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic 101 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 102 This document updates the Diameter peer discovery procedure described 103 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 104 and Application Protocol Tag values that permit the discovery of 105 Diameter peers that support a specific Diameter application and 106 transport protocol. 108 2. Terminology 110 The Diameter base protocol specification (Section 1.4 of [RFC3588]) 111 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 112 in [RFC3958]) define the terminology used in this document. 114 3. Extended NAPTR Service Field Format 116 The NAPTR Service Field format defined by the S-NAPTR DDDS 117 application in [RFC3958] follows this Augmented Backus-Naur Form 118 (ABNF, [RFC5234]): 120 service-parms = [ [app-service] *(":" app-protocol)] 121 app-service = experimental-service / iana-registered-service 122 app-protocol = experimental-protocol / iana-registered-protocol 123 experimental-service = "x-" 1*30ALPHANUMSYM 124 experimental-protocol = "x-" 1*30ALPHANUMSYM 125 iana-registered-service = ALPHA *31ALPHANUMSYM 126 iana-registered-protocol = ALPHA *31ALPHANUMSYM 127 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 128 DIGIT = %x30-39 ; 0-9 129 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 130 ALPHANUMSYM = ALPHA / DIGIT / SYM 131 ; The app-service and app-protocol tags are limited to 32 132 ; characters and must start with an alphabetic character. 133 ; The service-parms are considered case-insensitive. 135 This specification refines the "iana-registered-service" tag 136 definition for the discovery of Diameter agents supporting a specific 137 Diameter application as defined below. 139 iana-registered-service =/ aaa-service 140 aaa-service = "aaa+ap" appln-id 141 appln-id = 1*10DIGIT 142 ; Application identifier expressed as 143 ; a decimal integer without leading 144 ; zeros. 146 The appln-id element is the Application Identifier used to identify a 147 specific Diameter Application. The Diameter Application Identifier 148 is a 32-bit unsigned integer and values are allocated by IANA as 149 defined in [RFC3588]. 151 This specification also refines the "iana-registered-protocol" tag 152 definition for the discovery of Diameter agents supporting a specific 153 Diameter transport protocol as defined below. 155 iana-registered-protocol =/ aaa-protocol / 156 aaa-protocol = "diameter." aaa-transport 157 aaa-transport = "tcp" / "sctp" / "tls.tcp" 159 The S-NAPTR Application Protocol tags defined by this specification 160 MUST NOT be parsed in any way by the querying application or 161 resolver. The delimiter (".") is present in the tag to improve 162 readability and does not imply a structure or namespace of any kind. 163 The choice of delimiter (".") for the Application Protocol tag 164 follows the format of existing S-NAPTR Application Protocol tag 165 registry entries but this does not imply that that it shares 166 semantics with any other specifications that create registry entries 167 with the same format. 169 The S-NAPTR Application Service and Protocol tags defined by this 170 specification are unrelated to the IANA Service Name and Transport 171 Protocol Port Number Registry (see [I-D.ietf-tsvwg-iana-ports]). 173 The maximum length of the NAPTR service field is 256 octets including 174 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 175 of [RFC1035]). 177 3.1. IETF Standard Track Diameter Applications 179 A Diameter agent MUST be capable of using the extended S-NAPTR 180 Application Service Tag for dynamic discovery of a Diameter agent 181 supporting Standard Track applications. Therefore, every IETF 182 Standard Track Diameter application MUST be associated with a "aaa- 183 service" tag formatted as defined in this specification and allocated 184 in accordance with the IANA policy (see Section 7). 186 For example, a NAPTR service field value of: 188 'aaa+ap6:diameter.sctp' 190 Means that the Diameter node in the SRV or A/AAAA record supports 191 the Diameter Session Initiation Protocol (SIP) Application ('6') 192 and SCTP as the transport protocol. 194 3.2. Vendor-specific Diameter Applications 196 S-NAPTR Application Service and Application Protocol Tag values can 197 also be used to discover Diameter peers that support a vendor- 198 specific Diameter application. In this case, the vendor-specific 199 Diameter application MUST be associated with a "aaa-service" tag 200 formatted as defined in this specification and allocated in 201 accordance with the IANA policy (see Section 7). 203 For example, a NAPTR service field value of: 205 'aaa+ap16777251:diameter.sctp' 207 Means that the Diameter node in the SRV or A/AAAA record supports 208 the Diameter 3GPP S6a Application ('16777251') and SCTP as the 209 transport protocol. 211 4. Backwards Compatibility 213 Domain Name System (DNS) administrators SHOULD also provision legacy 214 RFC 3588 style NAPTR records [RFC3403] in order to guarantee 215 backwards compatibility with legacy RFC 3588 compliant Diameter 216 peers. If the DNS administrator provisions both extended S-NAPTR 217 records as defined in this specification and legacy RFC 3588 NAPTR 218 records, then the extended S-NAPTR records MUST have higher priority 219 (e.g. lower order and/or preference values) than legacy NAPTR 220 records. 222 5. Extended NAPTR-based Diameter Peer Discovery 224 The Diameter Peer Discovery principles are described in Section 5.2 225 of [RFC3588]. This specification updates the NAPTR query procedure 226 in the Diameter peer discovery mechanism by allowing the querying 227 node to determine which applications are supported by resolved 228 Diameter peers. 230 The extended format NAPTR records provide a mapping from a domain to 231 the SRV record or A/AAAA record for contacting a server supporting a 232 specific transport protocol and Diameter application. The resource 233 record will contain an empty regular expression and a replacement 234 value, which is the SRV record or the A/AAAA record for that 235 particular transport protocol. 237 The assumption for this mechanism to work is that the DNS 238 administrator of the queried domain has first provisioned the DNS 239 with extended format NAPTR entries. The steps below replace the 240 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 242 a. The Diameter implementation performs a NAPTR query for a server in 243 a particular realm. The Diameter implementation has to know in 244 advance which realm to look for a Diameter agent in and which 245 Application Identifier it is interested in. For example, the 246 realm could be deduced from the Network Access Identifier (NAI) in 247 the User-Name AVP or extracted from the Destination-Realm AVP. 249 b. If the returned NAPTR service fields contain entries formatted as 250 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 251 indicates the supported transport protocol(s), the target realm 252 supports the extended format for NAPTR-based Diameter peer 253 discovery defined in this document. 255 If "X" contains the required Application Identifier and "Y" 256 matches a supported transport protocol, the Diameter 257 implementation resolves the "replacement" field entry to a 258 target host using the lookup method appropriate for the "flags" 259 field. 261 If "X" does not contain the required Application Identifier or 262 "Y" does not match a supported transport protocol, the Diameter 263 implementation abandons the peer discovery. 265 c. If the returned NAPTR service fields contain entries formatted as 266 "aaa+apX" where "X" indicates the Application Identifier, the 267 target realm supports the extended format for NAPTR-based Diameter 268 peer discovery defined in this document. 270 If "X" contains the required Application Identifier, the 271 Diameter implementation resolves the "replacement" field entry 272 to a target host using the lookup method appropriate for the 273 "flags" field and attempts to connect using all supported 274 transport protocols following the order specified in section 275 2.1 of [RFC3588]. 277 If "X" does not contain the required Application Identifier, 278 the Diameter implementation abandons the peer discovery. 280 d. If the returned NAPTR service fields contain entries formatted as 281 "aaa:X" where "X" indicates the supported transport protocol(s), 282 the target realm supports Diameter but does not support the 283 extended format for NAPTR-based Diameter peer discovery defined in 284 this document. 286 If "X" matches a supported transport protocol, the Diameter 287 implementation resolves the "replacement" field entry to a 288 target host using the lookup method appropriate for the "flags" 289 field. 291 e. If the returned NAPTR service fields contain entries formatted as 292 "aaa", the target realm supports Diameter but does not support the 293 extended format for NAPTR-based Diameter peer discovery defined in 294 this document. The Diameter implementation resolves the 295 "replacement" field entry to a target host using the lookup method 296 appropriate for the "flags" field and attempts to connect using 297 all supported transport protocols following the order specified in 298 section 2.1 of [RFC3588]. 300 f. If the target realm does not support NAPTR-based Diameter peer 301 discovery, the client proceeds with the next peer discovery 302 mechanism described in Section 5.2 of [RFC3588]. 304 5.1. Examples 306 As an example, consider a client that wishes to discover a Diameter 307 server in the ex1.example.com realm that supports the Credit Control 308 Application. The client performs a NAPTR query for that domain, and 309 the following NAPTR records are returned: 311 ;; order pref flags service regexp replacement 312 IN NAPTR 50 50 "s" "aaa:diameter.sctp" "" 313 _diameter._sctp.ex1.example.com 314 IN NAPTR 50 50 "s" "aaa+ap1:diameter.sctp" "" 315 _diameter._sctp.ex1.example.com 316 IN NAPTR 50 50 "s" "aaa+ap4:diameter.sctp" "" 317 _diameter._sctp.ex1.example.com 319 This indicates that the server supports NASREQ (ID=1) and Credit 320 Control (ID=4) Applications over SCTP. If the client supports SCTP, 321 it will be used, targeted to a host determined by an SRV lookup of 322 _diameter._sctp.ex1.example.com. 324 That SRV lookup would return: 326 ;; Priority Weight Port Target 327 IN SRV 0 1 3868 server1.ex1.example.com 328 IN SRV 0 2 3868 server2.ex1.example.com 330 As an alternative example, a client that wishes to discover a 331 Diameter server in the ex2.example.com realm that supports the NASREQ 332 application over SCTP. The client performs a NAPTR query for that 333 domain, and the following NAPTR records are returned: 335 ;; order pref flags service regexp replacement 336 IN NAPTR 150 50 "a" "aaa:diameter.stcp" "" 337 server1.ex2.example.com 338 IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" 339 server2.ex2.example.com 340 IN NAPTR 150 50 "a" "aaa+ap1:diameter.stcp" "" 341 server1.ex2.example.com 342 IN NAPTR 150 50 "a" "aaa+ap1:diameter.tls.tcp" "" 343 server2.ex2.example.com 345 This indicates that the server supports NASREQ (ID=1) over SCTP and 346 TLS/TCP via hosts server1.ex2.example.com and server2.ex2.example.com 347 respectively. 349 6. Usage Guidelines 351 Diameter is a peer to peer protocol whereas most of the applications 352 that extend the base protocol behave like client/server applications. 353 The role of the peer is not advertised in the NAPTR tags and not even 354 communicated during Diameter capability negotiation (Capabilities- 355 Exchange-Request and Capabilities-Exchange-Answer message exchange). 356 For this reason, NAPTR-based Diameter peer discovery for an 357 application defining client/server roles should only be used by a 358 client to discover servers. 360 7. IANA Considerations 362 7.1. IETF Diameter Application Service Tags 364 IANA is requested to reserve a value of "aaa" for Diameter in the 365 S-NAPTR Application Service Tag registry created by [RFC3958]. IANA 366 is also requested to reserve the following S-NAPTR Application 367 Service Tags for existing IETF Diameter applications in the same 368 registry. 370 +------------------+----------------------------+ 371 | Tag | Diameter Application | 372 +------------------+----------------------------+ 373 | aaa+ap1 | NASREQ [RFC3588] | 374 | aaa+ap2 | Mobile IPv4 [RFC4004] | 375 | aaa+ap3 | Base Accounting [RFC3588] | 376 | aaa+ap4 | Credit Control [RFC4006] | 377 | aaa+ap5 | EAP [RFC4072] | 378 | aaa+ap6 | SIP [RFC4740] | 379 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 380 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 381 | aaa+ap9 | QoS [RFC5866] | 382 | aaa+ap4294967295 | Relay [RFC3588] | 383 +------------------+----------------------------+ 385 Future IETF Diameter applications MUST reserve the S-NAPTR 386 Application Service Tag corresponding to the allocated Diameter 387 Application ID as defined in Section 3. 389 7.2. 3GPP Diameter Application Service Tags 391 IANA is requested to reserve the following S-NAPTR Application 392 Service Tags for existing 3GPP Diameter applications in the S-NAPTR 393 Application Service Tag registry created by [RFC3958]. 395 +----------------+----------------------+ 396 | Tag | Diameter Application | 397 +----------------+----------------------+ 398 | aaa+ap16777250 | 3GPP STa [TS29.273] | 399 | aaa+ap16777251 | 3GPP S6a [TS29.272] | 400 | aaa+ap16777264 | 3GPP SWm [TS29.273] | 401 | aaa+ap16777267 | 3GPP S9 [TS29.215] | 402 +----------------+----------------------+ 404 Future 3GPP Diameter applications can reserve entries in the S-NAPTR 405 Application Service Tag registry created by [RFC3958] which 406 correspond to the allocated Diameter Application IDs as defined in 407 Section 3. 409 7.3. WiMAX Forum Diameter Application Service Tags 411 IANA is requested to reserve the following S-NAPTR Application 412 Service Tags for existing WiMAX Forum Diameter applications in the 413 S-NAPTR Application Service Tag registry created by [RFC3958]. 415 +----------------+--------------------------------------------------+ 416 | Tag | Diameter Application | 417 +----------------+--------------------------------------------------+ 418 | aaa+ap16777281 | WiMAX Network Access Authentication and | 419 | | Authorization Diameter Application (WNAAADA) | 420 | | [WiMAX] | 421 | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | 422 | | (WNADA) [WiMAX] | 423 | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | 424 | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | 425 | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | 426 | aaa+ap16777286 | WiMAX Location Authentication Authorization | 427 | | Diameter Application (WLAADA) [WiMAX] | 428 | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | 429 | | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | 430 | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | 431 | | Charging Diameter Application (WiMAX PCC-R3-OFC) | 432 | | [WiMAX] | 433 | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | 434 | | Charging Prime Diameter Application (WiMAX | 435 | | PCC-R3-OFC-PRIME) [WiMAX] | 436 | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | 437 | | Charging Diameter Application (WiMAX PCC-R3-OC) | 438 | | [WiMAX] | 439 +----------------+--------------------------------------------------+ 441 Future WiMAX Forum Diameter applications can reserve entries in the 442 S-NAPTR Application Service Tag registry created by [RFC3958] which 443 correspond to the allocated Diameter Application IDs as defined in 444 Section 3. 446 7.4. Vendor-Specific Diameter Application Service Tags 448 Vendor-Specific Diameter Application IDs are allocated by IANA 449 according to the "First Come First Served" policy and do not require 450 an IETF specification. However, the S-NAPTR Application Service Tag 451 registry created by [RFC3958] defines a registration policy of 452 "Specification Required" with a further stipulation that the 453 "specification" is an RFC (of any category). If a Vendor-Specific 454 Diameter Application requires the functionality defined in this 455 document, an RFC of any category MUST be published which reserves the 456 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 457 Diameter Application ID as defined in Section 3. 459 7.5. Diameter Application Protocol Tags 461 IANA is requested to reserve the following S-NAPTR Application 462 Protocol Tags for the Diameter transport protocols in the S-NAPTR 463 Application Protocol Tag registry created by [RFC3958]. 465 +------------------+----------+ 466 | Tag | Protocol | 467 +------------------+----------+ 468 | diameter.tcp | TCP | 469 | diameter.sctp | SCTP | 470 | diameter.tls.tcp | TLS/TCP | 471 +------------------+----------+ 473 Future Diameter versions which introduce new transport protocols MUST 474 reserve an appropriate S-NAPTR Application Protocol Tag in the 475 S-NAPTR Application Protocol Tag registry created by [RFC3958]. 477 8. Security Considerations 479 This document specifies an enhancement to RFC 3588 Diameter base 480 protocol defined NAPTR service field format and also modifications to 481 the NAPTR processing logic defined. The enhancements and 482 modifications are based on the S-NAPTR, which is actually a 483 simplification of the NAPTR, and therefore the same security 484 considerations described in RFC 3588 are applicable to this document. 485 No further extensions are required beyond the security mechanisms 486 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 487 learns applications supported by Diameter agents in a certain realm 488 faster, which might help the malicious host to scan potential targets 489 for an attack more efficiently when some applications have known 490 vulnerabilities. 492 9. Acknowledgments 494 We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien 495 Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete 496 Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms and 497 Joe Touch and for their comprehensive review comments. 499 10. Editor's Notes 501 This section to be removed prior to publication. 503 This draft updates sections of RFC3588 that are also being updated by 504 RFC3588bis. At the time this draft was started, it was uncertain 505 whether RFC3588bis would be published first. The authors of this 506 draft decided to proceed optimistically assuming this draft would be 507 published first with the understanding that minor updates are 508 required if this is not the case. 510 The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa: 511 diameter.sctp") were also contributed to RFC3588bis to ensure that it 512 would be functionally complete if it got published first and this 513 draft would come along later to add the application-specific S-NAPTR 514 entries (e.g."aaa+ap5:diameter.sctp"). 516 Depending on the publication order, the S-NAPTR Application Service 517 Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags 518 values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need 519 to be removed either from this draft or RFC3588bis. 521 11. Normative References 523 [I-D.ietf-tsvwg-iana-ports] 524 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 525 Cheshire, "Internet Assigned Numbers Authority (IANA) 526 Procedures for the Management of the Service Name and 527 Transport Protocol Port Number Registry", 528 draft-ietf-tsvwg-iana-ports-10 (work in progress), 529 February 2011. 531 [RFC1035] Mockapetris, P., "Domain names - implementation and 532 specification", STD 13, RFC 1035, November 1987. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 538 specifying the location of services (DNS SRV)", RFC 2782, 539 February 2000. 541 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 542 Part Three: The Domain Name System (DNS) Database", 543 RFC 3403, October 2002. 545 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 546 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 548 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 549 "DNS Extensions to Support IP Version 6", RFC 3596, 550 October 2003. 552 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 553 Service Location Using SRV RRs and the Dynamic Delegation 554 Discovery Service (DDDS)", RFC 3958, January 2005. 556 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 557 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 558 August 2005. 560 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 561 Loughney, "Diameter Credit-Control Application", RFC 4006, 562 August 2005. 564 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 565 Authentication Protocol (EAP) Application", RFC 4072, 566 August 2005. 568 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 569 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 570 Initiation Protocol (SIP) Application", RFC 4740, 571 November 2006. 573 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 574 Specifications: ABNF", STD 68, RFC 5234, January 2008. 576 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 577 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 578 Agent to Diameter Server Interaction", RFC 5778, 579 February 2010. 581 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 582 and G. Zorn, "Diameter Quality-of-Service Application", 583 RFC 5866, May 2010. 585 [TS29.215] 586 3rd Generation Partnership Project, "3GPP TS 29.215; 587 Technical Specification Group Core Network and Terminals; 588 Policy and Charging Control (PCC) over S9 reference point; 589 Stage 3 (Release 8)", 590 . 592 [TS29.272] 593 3rd Generation Partnership Project, "3GPP TS 29.272; 594 Technical Specification Group Core Network and Terminals; 595 Evolved Packet System; Mobility Management Entity (MME) 596 and Serving GPRS Support Node (SGSN) Related Interfaces 597 Based on Diameter Protocol (Release 8)", 598 . 600 [TS29.273] 601 3rd Generation Partnership Project, "3GPP TS 29.273; 602 Technical Specification Group Core Network and Terminals; 603 Evolved Packet System; 3GPP EPS AAA interfaces (Release 604 8)", . 606 [WiMAX] WiMAX Forum, "WiMAX Release 1.5", . 609 Authors' Addresses 611 Mark Jones 612 Bridgewater Systems 614 Email: mark@azu.ca 616 Jouni Korhonen 617 Nokia Siemens Networks 619 Email: jouni.nospam@gmail.com 621 Lionel Morand 622 Orange Labs 624 Email: lionel.morand@orange-ftgroup.com