idnits 2.17.1 draft-ymbk-dns-choices-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 469. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 485), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 71 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 14, 2004) is 7287 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 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2916 (Obsoleted by RFC 3761) ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Faltstrom 2 Internet-Draft Cisco 3 Expires: November 12, 2004 R. Austein 4 ISC 5 May 14, 2004 7 Design Choices When Expanding DNS 8 draft-ymbk-dns-choices-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 12, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This note discusses how to extend the DNS with new data for a new 42 application. DNS extension discussion too often circulate around 43 reuse of the TXT record. This document lists different mechanisms to 44 accomplish the extension to DNS, and comes to the conclusion use of a 45 new RR Type is the best solution. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4 53 3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 4 54 3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 5 55 3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 5 56 3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 6 57 4. The case against protocol use of TXT RRs . . . . . . . . . . . 6 58 5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 8 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . 11 65 1. Introduction 67 The DNS stores multiple categories of data. The two most commonly 68 used categories are infrastructure data for the DNS system itself (NS 69 and SOA records) and data which have to do with mappings between 70 domain names and IP addresses (A, AAAA and PTR). There are other 71 categories as well, some of which are tied to specific applications 72 like email (MX), while others are generic record types used to convey 73 information for multiple protocols (SRV, NAPTR). 75 When storing data in the DNS for a new application, the data are 76 usually tied to a "normal" domain name, so the application can query 77 for the data it wants, while minimizing the impact on existing 78 applications. 80 Historically, extension of DNS to store data for applications tied to 81 a domain name has been done in different ways at different times. MX 82 records were created as a new resource record type specifically 83 designed to support electronic mail. SRV records are a generic type 84 which use a prefixing scheme in combination with a base domain name. 85 Records associated with ENUM use a suffixing scheme. NAPTR records 86 add selection data inside the RDATA. It is clear the way of adding 87 new data to the DNS has been inconsistent, and the purpose of this 88 document is to attempt to clarify the implications of each of these 89 methods, both for the applications that use them and for the rest of 90 the DNS system. 92 2. Background 94 See RFC 2929 [RFC2929] for a brief summary of DNS query structure. 95 Readers interested in the full story should start with the base DNS 96 specification in RFC 1035 [RFC1035], and continue with the various 97 documents which update, clarify, and extend the base specification. 99 When composing a query into the DNS system, the parameters actually 100 used by the protocol are a triple: a DNS name, a DNS class, and a DNS 101 record type. Every resource record (RR) matching a particular name, 102 type and class is said to belong to the same resource record set 103 (RRset), and the whole RRset is always returned to the client which 104 queries for it. Splitting an RRset is a protocol violation, because 105 it results in coherency problems with the DNS caching mechanism. 107 3. Extension mechanisms 109 The DNS protocol is intended to be extensible to support new kinds of 110 data. This section examines the various ways in which this sort of 111 extension can be accomplished. 113 3.1 Place selectors inside the RDATA 115 For a given query name, one might choose to have a single RRset (all 116 sharing the same name, type, and class) shared by multiple 117 applications, and have the different applications use selectors 118 within the RR data (RDATA) to determine which records are intended 119 for which applications. This sort of selector mechanism is usually 120 referred to "subtyping", because it is in effect creating an 121 additional type subsystem within a single DNS RR type. 123 Examples of subtyping include NAPTR RRs (see RFC 2916 [RFC2916]) and 124 the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was 125 updated by RFC 3445 [RFC3445]). 127 All DNS subtyping schemes share a common weakness: With subtyping 128 schemes it is impossible for a client to query for just the data it 129 wants. Instead, the client must fetch the entire RRset, then select 130 the RRs in which it is interested. Furthermore, since DNSSEC 131 signatures operate on complete RRsets, the entire RRset must be 132 re-signed if any RR in it changes. As a result, each application 133 that uses a subtyped RR incurs higher overhead than any of the 134 applications would have incurred had they not been using a subtyping 135 scheme. The fact the RRset is always passed around as an indivisible 136 unit increases the risk the RRset will not fit in a UDP packet, which 137 in turn increases the risk that the client will have to retry the 138 query with TCP, which substantially increases the load on the name 139 server. More precisely: Having one query fail over to TCP is not a 140 big deal, but since the typical ratio of clients to servers in the 141 DNS system is very high, having a substantial number of DNS messages 142 fail over to TCP it will cause the relevant name servers to be 143 "nibbled to death by ducks". 145 The final result of using a subtyping scheme might be that the zone 146 administrator has to choose which of the services tied to one domain 147 name can actually be used, because not all of them will be usable at 148 the same time. 150 3.2 Add a prefix to the owner name 152 By adding an application-specific prefix to a domain name, we will 153 get different name/class/type triples, and therefore different 154 RRsets. The problem with adding prefixes has to do with wildcards, 155 especially if one has records like "*.example.com. IN MX 1 156 mail.example.com" and one wants records tied to those names. Suppose 157 one creates the prefix "_mail". One would then have to say something 158 like "_mail.*.example.com", but DNS wildcards only work with the "*" 159 as the leftmost token in the domain name. 161 Even when a specific prefix is chosen, the data will still have to be 162 stored in some RR type. This RR type can either be a "kitchen-sink 163 record" or a new RR type. This implies that some other mechanism has 164 to be applied as well, with implications detailed in other parts of 165 this note. 167 3.3 Add a suffix to the owner name 169 Adding a suffix to a domain name changes the name/class/type triple, 170 and therefore the RRset. The query name can be set to exactly the 171 data one wants, and the size of the RRset is minimized. The problem 172 with adding a suffix is that it creates a parallel tree within the IN 173 class. There will be no technical mechanism to ensure that the 174 delegation for "example.com" and "example.com._bar" are made to the 175 same organization. Furthermore, data associated with a single entity 176 will now be stored in two different zones, such as "example.com" and 177 "example.com._bar", which, depending on who controls "_bar", can 178 create new synchronization and update authorization issues. 180 Even when using a different name, the data will still have to be 181 stored in some RR type. This RR type can either be a "kitchen-sink 182 record" or a new RR type. This implies that some other mechanism has 183 to be applied as well, with implications detailed in other parts of 184 this note. 186 3.4 Add a new Class 188 DNS zones are class-specific, in the sense that all the records in 189 that zone share the same class as the zone's SOA record, and the 190 existence of a zone in one class does not guarantee the existence of 191 the zone in any other class. In practice, only the IN class has ever 192 seen widespread deployment, and the administrative overhead of 193 deploying an additional class would almost certainly be prohibitive. 195 Nevertheless, one could in theory use the DNS class mechanism to 196 distinguish between different kinds of data. However, since the DNS 197 delegation tree (represented by NS RRs) is itself tied to a specific 198 class, attempting to resolve a query by crossing a class boundary may 199 produce unexpected results, because there is no guarantee that the 200 name servers for the zone in in the new class will be the same as the 201 name servers in the IN class. The MIT Hesiod system used a scheme 202 like this for storing data in the HS class, but only on a very small 203 scale (within a single institution), and with an administrative fiat 204 requiring that the delegation trees for the IN and HS trees be 205 identical. 207 Even when using a different class, the data will still have to be 208 stored in some RR type or another. This RR type can either be a 209 "kitchen-sink record" or a new RR type. This implies that some other 210 mechanism has to be applied as well, with implications detailed in 211 other parts of this note. 213 3.5 Add a new Resource Record Type 215 When adding a new Resource Record type to the system, entities in 216 four different roles have to be able to handle the new type: 218 1. There must be a way to insert the new resource records in a 219 Master authoritative name servers. For some server 220 implementations, the user interface only accepts record types 221 which it understands (perhaps so that the implementation can 222 attempt to validate the data). Other implementations allow the 223 zone administrator to enter an integer for the resource record 224 type code and the RDATA in Base64 or hexadecimal encoding (or 225 even as raw data). RFC 3597 [RFC3597] specifies a standard 226 generic encoding for this purpose. 227 2. A slave authoritative name server must be able to do a zone 228 transfer, receive the data from some other authoritative name 229 server, and serve data from the zone even though the zone 230 includes records of unknown types. Historically, some 231 implementations have had problems parsing stored copies of the 232 zone file after restarting, but those problems have not been seen 233 for a few years. 234 3. A full service resolver will cache the records which are 235 responses to queries. As mentioned in RFC 3597 [RFC3597],there 236 are various pitfalls where a recursive name server might end up 237 having problems. 238 4. The application must be able to get the record with a new 239 resource record type. The application itself may understand the 240 RDATA, but the resolver library might not. Support for a generic 241 interface for retrieving arbitrary DNS RR types has been a 242 requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). 243 Some stub resolver library implementations neglect to provide 244 this functionality and cannot handle unknown RR types, but 245 implementation of a new stub resolver library is not particularly 246 difficult, and open source libraries that already provide this 247 functionality are available. 249 4. The case against protocol use of TXT RRs 251 By now, the astute reader will be wondering about the apparent 252 disconnect between the title of this note and the issues presented so 253 far. We will now attempt to clear up the reader's confusion by 254 following the thought processes of a typical application designer who 255 wishes to store stuff in the DNS, showing how such a designer almost 256 inevitably hits upon the idea of just using TXT RR, and why this is a 257 bad thing. 259 A typical application designer is not interested in the DNS for its 260 own sake, but rather as a distributed database in which application 261 data can be stored. As a result, the designer of a new application 262 is usually looking for the easiest way to add whatever new data the 263 application needs to the DNS in a way that naturally associates the 264 data with a DNS name. 266 As explained in Section 3.4, using the DNS class system as an 267 extension mechanism is not really an option, and in fact most users 268 of the system don't even realize that the mechanism exists. As a 269 practical matter, therefore any extension is likely to be within the 270 IN class. 272 Adding a new RR type is the technically correct answer from the DNS 273 protocol standpoint (more on this below), doing so requires some DNS 274 expertise, due to the issues listed in Section 3.5. As a result, 275 this option is usually considered too hard. 277 The application designer is thus left with the prospect of reusing 278 some existing DNS type within the IN class, but when the designer 279 looks at the existing types, almost all of them have well-defined 280 semantics, none of which quite match the needs of the new 281 application. This has not completely prevented proposals to reuse 282 existing RR types in ways incompatible with their defined semantics, 283 but it does tend to steer application designers away from this 284 approach. 286 Eliminating all of the above leaves the TXT RR type in the IN class. 287 The TXT RDATA format is free form text, and there are no existing 288 semantics to get in the way. Furthermore, the TXT RR can obviously 289 just be used as a bucket in which to carry around data to be used by 290 some higher level parser, perhaps in some human readable programming 291 or markup language. Thus, for many applications, TXT RRs are the 292 "obvious" choice. Unfortunately, this conclusion, while 293 understandable, is also wrong, for several reasons. 295 The first reason why TXT RRs are not well suited to such use is 296 precisely the lack of defined semantics that make them so attractive. 297 Arguably, the TXT RR is misnamed, and should have been called the 298 Humpty Dumpty record, because the lack of defined semantics means 299 that a TXT RR means precisely what the data producer says it means. 300 This is fine, so long as TXT RRs are being used by human beings or by 301 private agreement between data producer and data consumer. However, 302 once one starts using them for standardized protocols in which there 303 is no prior relationship between data producer and data consumer, the 304 lack of defined semantics becomes a problem, because there is nothing 305 to prevent collisions some other incompatible use of TXT RRs. This 306 is even worse than the general subtyping problem described in Section 307 3.1, because TXT RRs don't even have a standardized selector field in 308 which to store the subtype. At best one is reduced to hoping that 309 whatever subtyping scheme one has come up with will not accidently 310 conflict with somebody else's subtyping scheme, and that it will not 311 be possible to mis-parse one application's use of TXT RRs as data 312 intended for a different application. Any attempt to come up with a 313 standardized format within the TXT RR format would be at least 314 fifteen years too late even if it were put into effect immediately. 316 Using one of the naming modifications discussed in Section 3.2 and 317 Section 3.3 would address the subtyping problem, but each of these 318 approaches brings in new problems of its own. The prefix approach 319 (such as SRV RRs use) does not work well with wildcards, which is a 320 particular problem for mail-related applications, since MX RRs are 321 probably the most common use of DNS wildcards. The suffix approach 322 doesn't have wildcard issues, but, as noted previously, it does have 323 synchronization and update authorization issues, since it works by 324 creating a second subtree in a different part of the global DNS name 325 space. 327 The next reason why TXT RRs are not well suited to protocol use has 328 to do with the limited data space available in a DNS message. As 329 alluded to briefly in Section 3.1, typical DNS query traffic patterns 330 involve a very large number of DNS clients sending queries to a 331 relatively small number of DNS servers. Normal path MTU discovery 332 schemes do little good here, because, from the server's perspective, 333 there isn't enough repeat traffic from any one client for it to be 334 worth retaining state. UDP-based DNS is an idempotent query, whereas 335 TCP-based DNS requires the server to keep state (in the form of TCP 336 connection state, usually in the server's kernel) and roughly triples 337 the traffic load. Thus, there's a strong incentive to keep DNS 338 messages short enough to fit in a UDP datagram, preferably a UDP 339 datagram short enough not to require IP fragmentation. Subtyping 340 schemes are therefore again problematic, because they produce larger 341 RRsets than necessary, but verbose text encodings of data are also 342 wasteful, since the data they hold can usually be represented more 343 compactly in a resource record designed specifically to support the 344 application's particular data needs. If the data that need to be 345 carried are so large that there is no way to make them fit 346 comfortably into the DNS regardless of encoding, it is probably 347 better to move the data somewhere else, and just use the DNS as a 348 pointer to the data, as with NAPTR. 350 5. Conclusion and Recommendation 352 Given the problems detailed in Section 4, it is worth reexamining the 353 oft-jumped-to conclusion that specifying a new RR type is hard. 354 Historically, this was indeed the case, but recent surveys suggest 355 that support for unknown RR types [RFC3597] is now widespread, and 356 that lack of support for unknown types is mostly an issue for 357 relatively old software that would probably need to be upgraded in 358 any case as part of supporting a new application. In particular, any 359 new protocol that proposes to use the DNS to store data used to make 360 authorization decisions would be well advised not only to use DNSSEC 361 but also to encourage upgrades to DNS server software recent enough 362 not to be riddled with well-known exploitable bugs. 364 Of all the issues detailed in Section 3.5, provisioning the data is 365 in some respects the most difficult. The problem here is less the 366 authoritative name servers themselves than the front-end systems used 367 to enter (and perhaps validate) the data. Hand editing does not work 368 well for maintenance of large zones, so some sort of tool is 369 necessary, and the tool may not be tightly coupled to the name server 370 implementation itself. Note, however, that this provisioning problem 371 exists to some degree with any new form of data to be stored in the 372 DNS, regardless of data format, RR type, or naming scheme. Adapting 373 front-end systems to support a new RR type may be a bit more 374 difficult than reusing an existing type, but this appears to be a 375 minor difference in degree rather than a difference in kind. 377 Given the various issues described in this note, we believe that: 378 o there is no magic solution which allows a completely painless 379 addition of new data to the DNS, but 380 o on the whole, the best solution is still to use the DNS type 381 mechanism designed for precisely this purpose, and 382 o of all the alternate solutions, the "obvious" approach of using 383 TXT RRs is almost certainly the worst. 385 6. IANA Considerations 387 This document does not require any IANA actions. 389 7. Security Considerations 391 DNS RRsets can be signed using DNSSEC. DNSSEC is almost certainly 392 necessary for any application mechanism that stores authorization 393 data in the DNS itself. DNSSEC signatures significantly increase the 394 size of the messages transported, and because of this, the DNS 395 message size issues discussed in Section 3.1 and Section 4 are more 396 serious than they might at first appear. 398 Adding new RR types (as discussed in Section 3.5 might conceivably 399 trigger bugs and other bad behavior in software which is not 400 compliant with RFC 3597 [RFC3597], but most such software is old 401 enough and insecure enough that it should be updated for other 402 reasons in any case. Basic API support for retrieving arbitrary RR 403 types has been a requirement since RFC 1123 [RFC1123]. 405 8 References 407 [RFC1035] Mockapetris, P., "Domain names - implementation and 408 specification", STD 13, RFC 1035, November 1987. 410 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 411 and Support", STD 3, RFC 1123, October 1989. 413 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 414 RFC 2535, March 1999. 416 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 417 2000. 419 [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain 420 Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 421 September 2000. 423 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 424 Resource Record (RR)", RFC 3445, December 2002. 426 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 427 (RR) Types", RFC 3597, September 2003. 429 Authors' Addresses 431 Patrik Faltstrom 432 Cisco Systems, Inc. 433 Ledasa 434 Lovestad 273 71 435 Sweden 437 EMail: paf@cisco.com 439 Rob Austein 440 Internet Systems Consortium 441 950 Charter Street 442 Redwood City, CA 94063 443 USA 445 EMail: sra@isc.org 447 Intellectual Property Statement 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed to 451 pertain to the implementation or use of the technology described in 452 this document or the extent to which any license under such rights 453 might or might not be available; nor does it represent that it has 454 made any independent effort to identify any such rights. Information 455 on the procedures with respect to rights in RFC documents can be 456 found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use of 461 such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository at 463 http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention any 466 copyrights, patents or patent applications, or other proprietary 467 rights that may cover technology that may be required to implement 468 this standard. Please address the information to the IETF at 469 ietf-ipr@ietf.org. 471 Disclaimer of Validity 473 This document and the information contained herein are provided on an 474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 476 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 477 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 478 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 Copyright Statement 483 Copyright (C) The Internet Society (2004). This document is subject 484 to the rights, licenses and restrictions contained in BCP 78, and 485 except as set forth therein, the authors retain all their rights. 487 Acknowledgment 489 Funding for the RFC Editor function is currently provided by the 490 Internet Society.