idnits 2.17.1 draft-irtf-asrg-dnsbl-07.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 10, 2008) is 5670 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Anti-Spam Research Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track October 10, 2008 5 Expires: April 13, 2009 7 DNS Blacklists and Whitelists 8 draft-irtf-asrg-dnsbl-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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 April 13, 2009. 35 Abstract 37 The rise of spam and other anti-social behavior on the Internet has 38 led to the creation of shared blacklists and whitelists of IP 39 addresses or domains. The DNS has become a de-facto standard method 40 of distributing these blacklists and whitelists. This memo documents 41 the structure and usage of DNS based blacklists and whitelists, and 42 the protocol used to query them. 44 IRTF Notice 46 This document is a product of the Anti-Spam Research Group (ASRG). 47 Comments and discussion may be directed to the ASRG mailing list, 48 asrg@irtf.org. 50 This document represents the consensus of the Anti-Spam Research 51 Group of the Internet Research Task Force. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Structure of an IP address DNSBL or DNSWL . . . . . . . . . . 3 57 2.1. IP address DNSxL . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. IP address DNSWL . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Combined IP address DNSxL . . . . . . . . . . . . . . . . 5 60 2.4. IPv6 DNSxLs . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Domain name DNSxLs . . . . . . . . . . . . . . . . . . . . . . 6 62 4. DNSxL cache behavior . . . . . . . . . . . . . . . . . . . . . 7 63 5. Test and contact addresses . . . . . . . . . . . . . . . . . . 7 64 6. Typical usage of DNSBLs and DNSWLs . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 71 A.1. Changes since -asrg-dnsbl-06 . . . . . . . . . . . . . . . 10 72 A.2. Changes since -asrg-dnsbl-05 . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Introduction 78 In 1997, Dave Rand and Paul Vixie, well known Internet software 79 engineers, started keeping a list of IP addresses that had sent them 80 spam or engaged in other behavior that they found objectionable. 81 Word of the list quickly spread, and they started distributing it as 82 a BGP feed for people who wanted to block all traffic from listed IP 83 addresses at their routers. The list became known as the Real-time 84 Blackhole List (RBL). 86 Many network managers wanted to use the RBL to block unwanted e-mail, 87 but weren't prepared to use a BGP feed. Rand and Vixie created a 88 DNS-based distribution scheme that quickly became more popular than 89 the original BGP distribution. Other people created other DNS-based 90 blacklists either to compete with the RBL or to complement it by 91 listing different categories of IP addresses. Although some people 92 refer to all DNS-based blacklists as ``RBLs'', the term properly is 93 used for the MAPS RBL, the descendant of the original list. (In the 94 United States, the term RBL is a registered service mark of Trend 95 Micro[MAPSRBL].) 97 The conventional term is now DNS Blacklist or Blocklist, or DNSBL. 98 Some people also publish DNS-based whitelists or DNSWLs. Network 99 managers typically use DNSBLs to block traffic and DNSWLs to 100 preferentially accept traffic. The structure of a DNSBL and DNSWL 101 are the same, so in the subsequent discussion we use the abbreviation 102 DNSxL to mean either. 104 This document defines the structure of DNSBLs and DNSWLs. It 105 describes the structure, operation, and use of DNSBLs and DNSWLs but 106 does not describe or recommend policies for adding or removing 107 addresses to and from DNSBLs and DNSWLs, nor does it recommend 108 policies for using them. We anticipate that management policies will 109 be addressed in a companion document. 111 Requirements Notation: The key words "MUST", "MUST NOT", 112 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 113 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 114 interpreted as described in [RFC2119]. 116 2. Structure of an IP address DNSBL or DNSWL 118 A DNSxL is a zone in the DNS[RFC1034][RFC1035]. The zone containing 119 resource records identifies hosts present in a blacklist or 120 whitelist. Hosts were originally encoded into DNSxL zones using a 121 transformation of their IP addresses, but now host names are 122 sometimes encoded as well. Most DNSxLs still use IP addresses. 124 2.1. IP address DNSxL 126 An IPv4 address DNSxL has a structure adapted from that of the rDNS. 127 (The rDNS, reverse DNS, is the IN-ADDR.ARPA[RFC1034] and 128 IP6.ARPA[RFC3596] domains used to map IP addresses to domain names.) 129 Each IPv4 address listed in the DNSxL has a corresponding DNS entry 130 created by reversing the order of the octets of the text 131 representation of the IP address, and appending the domain name of 132 the DNSxL. 134 If, for example, the DNSxL is called bad.example.com, and the IPv4 135 address to be listed is 192.0.2.99, the name of the DNS entry would 136 be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an 137 A record. DNSBLs SHOULD have a TXT record that describes the reason 138 for the entry. DNSWLs MAY have a TXT record that describes the 139 reason for the entry. The A record conventionally has the value 140 127.0.0.2, but MAY have other values as described below in Combined 141 IP address DNSxLs. The TXT record describes the reason that the IP 142 is listed in the DNSxL, and is often used as the text of an SMTP 143 error response when an SMTP client attempts to send mail to a server 144 using the list as a DNSBL, or as explanatory text when the DNSBL is 145 used in a scoring spam filter. The DNS records for this entry might 146 be: 148 99.2.0.192.bad.example.com A 127.0.0.2 149 99.2.0.192.bad.example.com TXT 150 "Dynamic address, see http://bad.example.com?192.0.2.99" 152 Some DNSxLs use the same TXT record for all entries, while others 153 provide a different TXT record for each entry or range of entries 154 that describes the reason that entry or range is listed. The reason 155 often includes the URL of a web page where more information is 156 available. Client software MUST check the A record and MAY check the 157 TXT record. 159 If a range of addresses is listed in the DNSxL, the DNSxL MUST 160 contain an A record (or a pair of A and TXT records) for every 161 address in the DNSxL. Conversely, if an IP address is not listed in 162 the DNSxL, there MUST NOT be any records for the address. 164 2.2. IP address DNSWL 166 Since SMTP has no standard way for a server to advise a client why a 167 request was accepted, TXT records in DNSWLs are not very useful. 168 Some DNSWLs contain TXT records anyway to document the reasons that 169 entries are present. 171 It is possible and occasionally useful for a DNSxL to be used as a 172 DNSBL in one context and a DNSWL in another. For example, a DNSxL 173 that lists the IP addresses assigned to dynamically assigned 174 addresses on a particular network might be used as a DNSWL on that 175 network's outgoing mail server or intranet web server, and used as a 176 DNSBL for mail servers on other networks. 178 2.3. Combined IP address DNSxL 180 In many cases, an organization maintains a DNSxL that contains 181 multiple entry types, with the entries of each type constituting a 182 sublist. For example, an organization that publishes a DNSBL listing 183 sources of unwanted e-mail might wish to indicate why various 184 addresses are included in the list, with one sublist for addresses 185 listed due to sender policy, a second list for addresses of open 186 relays, a third list for hosts compromised by malware, and so forth. 187 (At this point all of the DNSxLs with sublists of which we are aware 188 are intended for use as DNSBLs, but the sublist techniques are 189 equally usable for DNSWLs.) 191 There are three common methods of representing a DNSxL with multiple 192 sublists: subdomains, multiple A records, and bit encoded entries. 193 DNSxLs with sublists SHOULD use both subdomains and one of the other 194 methods. 196 Sublist subdomains are merely subdomains of the main DNSxL domain. 197 If for example, bad.example.com had two sublists relay and malware, 198 entries for 192.0.2.99 would be 99.2.0.192.relay.bad.example.com or 199 99.2.0.192.malware.bad.example.com. If a DNSxL contains both entries 200 for a main domain and for sublists, sublist names MUST be at least 201 two characters and contain non-digits, so there is no problem of name 202 collisions with entries in the main domain, where the IP addresses 203 consist of digits or single hex characters. 205 To minimize the number of DNS lookups, multiple sublists can also be 206 encoded as bit masks or multiple A records. With bit masks, the A 207 record entry for each IP is the logical OR of the bit masks for all 208 of the lists on which the IP appears. For example, the bit masks for 209 the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an 210 entry for an IP on both lists would be 127.0.0.6: 212 99.2.0.192.bad.example.com A 127.0.0.6 214 With multiple A records, each sublist has a different assigned value 215 such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each 216 sublist on which the IP appears: 218 99.2.0.192.bad.example.com A 127.0.1.1 219 99.2.0.192.bad.example.com A 127.0.1.2 220 There is no widely used convention for mapping sublist names to bits 221 or values, beyond the convention that all A values SHOULD be in the 222 127.0.0.0/8 range to prevent unwanted network traffic if the value is 223 accidentally used as an IP address. 225 DNSxLs that return multiple A records sometimes return multiple TXT 226 records as well, although the lack of any way to match the TXT 227 records to the A records limits the usefulness of those TXT records. 228 Other combined DNSxLs return a single TXT record. 230 2.4. IPv6 DNSxLs 232 The structure of DNSxLs based on IPv6 addresses is adapted from that 233 of the IP6.ARPA domain defined in [RFC3596]. Each entry MUST be a 234 32-component hex nibble-reversed IPv6 addresses suffixed by the the 235 DNSxL domain. For example, to represent the address: 237 2001:db8:1:2:3:4:567:89ab 239 in the DNSxL ugly.example.com, the entry might be: 241 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. 242 ugly.example.com. A 127.0.0.2 243 TXT "Spam received." 245 Combined IPv6 sublist DNSxLs are represented the same way as IPv4 246 DNSxLs, replacing the four octets of IPv4 address with the 32 nibbles 247 of IPv6 address. 249 A single DNSxL could in principle contain both IPv4 and IPv6 250 addresses, since the different lengths prevent any ambiguity. If a 251 DNSxL is represented using traditional zone files and wildcards, 252 there is no way to specify the length of the name that a wildcard 253 matches, so wildcard names would indeed be ambiguous for DNSxLs 254 served in that fashion. 256 3. Domain name DNSxLs 258 A few DNSxLs list domain names rather than IP addresses. They are 259 sometimes called RHSBLs, for right hand side blacklists. The names 260 of their entries MUST contain the listed domain name followed by the 261 name of the DNSxL. If the DNSxL were called doms.example.net, and 262 the domain invalid.edu were to be listed, the entry would be named 263 invalid.edu.doms.example.net: 265 invalid.edu.doms.example.net A 127.0.0.2 266 invalid.edu.doms.example.net TXT "Host name used in phish" 267 Name-based DNSBLs are far less common than IP based DNSBLs. There is 268 no agreed convention for wildcards. 270 Name-based DNSWLs can be created in the same manner as DNSBLs, and 271 have been used as simple reputation systems with the values of octets 272 in the A record representing reputation scores and confidence values, 273 typically on a 0-100 or 0-255 scale. 275 4. DNSxL cache behavior 277 The per-record time-to-live and zone refresh intervals of DNSBLs and 278 DNSWLs vary greatly depending on the management policy of the list. 279 The TTL and refresh times SHOULD be chosen to reflect the expected 280 rate of change of the DNSxL. A list of IP addresses assigned to 281 dynamically allocated dialup and DHCP users could be expected to 282 change slowly, so the TTL might be several days and the zone 283 refreshed once a day. On the other hand, a list of IP addresses that 284 had been observed sending spam might change every few minutes, with 285 comparably short TTL and refresh intervals. 287 5. Test and contact addresses 289 IPv4 based DNSxLs MUST contain an entry for 127.0.0.2 for testing 290 purposes. IPv4 based DNSxLs MUST NOT contain an entry for 127.0.0.1. 292 DNSBLs that return multiple values SHOULD have multiple test 293 addresses so that, for example, a DNSBL that can return 127.0.0.5 294 would have a test record for 127.0.0.5 that returns an A record with 295 the value 127.0.0.5, and a corresponding TXT record. 297 IPv6 based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: 298 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: 299 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the 300 IPv4 test addresses. 302 Domain name based DNSxLs MUST contain an entry for the [RFC2606] 303 reserved domain name "TEST" and MUST NOT contain an entry for the 304 reserved domain name "INVALID". 306 DNSxLs also MAY contain an A record at the apex of the DNSxL zone 307 that points to a web server, so that anyone wishing to learn about 308 the bad.example.net DNSBL can check http://bad.example.net. 310 The combination of a test address that MUST exist and an address that 311 MUST NOT exist allows a client system to defend against DNSxLs which 312 deliberately or by accident install a wildcard that returns an A 313 record for all queries. DNSxL clients SHOULD periodically check 314 appropriate test entries to ensure that the DNSxLs they are using are 315 still operating. 317 6. Typical usage of DNSBLs and DNSWLs 319 DNSxLs can be served either from standard DNS servers, or from 320 specialized servers like rbldns [RBLDNS] and rbldnsd [RBLDNSD] that 321 accept lists of IP addresses and CIDR ranges and synthesize the 322 appropriate DNS records on the fly. Organizations that make heavy 323 use of a DNSxL usually arrange for a private mirror of the DNSxL, 324 either using the standard AXFR and IXFR or by fetching a file 325 containing addresses and CIDR ranges for the specialized servers. If 326 a /24 or larger range of addresses is listed, and the zone's server 327 uses traditional zone files to represent the DNSxL, the DNSxL MAY use 328 wildcards to limit the size of the zone file. If for example, the 329 entire range of 192.0.2.0/24 were listed, the DNSxL's zone could 330 contain a single wildcard for *.2.0.192.bad.example.com. 332 DNSBL clients are most often mail servers or spam filters called from 333 mail servers. There's no requirement that DNSBLs be used only for 334 mail, and other services such as IRC use them to check client hosts 335 that attempt to connect to a server. 337 A client MUST interpret any returned A record as meaning that an 338 address or domain is listed in a DNSxL. Mail servers that test 339 combined lists most often handle them the same as single lists and 340 treat any A record as meaning that an IP is listed without 341 distinguishing among the various reasons it might have been listed. 342 DNSxL clients SHOULD be able to use bit masks and value range tests 343 on returned A record values in order to select particular sublists of 344 a combined list. 346 Mail servers typically check a list of DNSxLs on every incoming SMTP 347 connection, with the names of the DNSxLs set in the server's 348 configuration. A common usage pattern is for the server to check 349 each list in turn until it finds one with a DNSBL entry, in which 350 case it rejects the connection, or a DNSWL entry in which case it 351 accepts the connection. If the address appears on no list at all 352 (the usual case for legitimate mail), the mail server accepts the 353 connection. In another approach, DNSxL entries are used as inputs to 354 a weighting function that computes an overall score for each message. 356 The mail server uses its normal local DNS cache to limit traffic to 357 the DNSxL servers and to speed up retests of IP addresses recently 358 seen. Long-running mail servers MAY cache DNSxL data internally, but 359 MUST respect the TTL values and discard expired records. 361 An alternate approach is to check DNSxLs in a spam filtering package 362 after a message has been received. In that case, the IP(s) to test 363 are usually extracted from "Received:" header fields or URIs in the 364 body of the message. The DNSxL results can be used to make a binary 365 accept/reject decision, or in a scoring system. 367 Packages that test multiple header fields MUST be able to distinguish 368 among values in lists with sublists since, for example, an entry 369 indicating that an IP is assigned to dialup users might be treated as 370 a strong indication that a message would be rejected if the IP sends 371 mail directly to the recipient system, but not if the message were 372 relayed through an ISP's mail server. 374 Name-based DNSBLs have been used both to check domain names of e-mail 375 addresses and host names found in mail headers, and to check the 376 domains found in URLs in message bodies. 378 7. Security Considerations 380 Any system manager that uses DNSxLs is entrusting part of his or her 381 server management to the parties that run the lists. A DNSBL manager 382 that decided to list 0/0 (which has actually happened) could cause 383 every server that uses the DNSBL to reject all mail. Conversely, if 384 a DNSBL manager removes all of the entries (which has also happened), 385 systems that depend on the DNSBL will find that their filtering 386 doesn't work as they want it to. 388 Since DNSxL users usually make a query for every incoming e-mail 389 message, the operator of a DNSxL can extract approximate mail volume 390 statistics from the DNS server logs. This has been used in a few 391 instances to estimate the amount of mail individual IPs or IP blocks 392 send[SENDERBASE] [KSN]. 394 As with any other DNS based services, DNSBLs and DNSWLs are subject 395 to various types of DNS attacks which are described in [RFC3833]. 397 8. IANA Considerations 399 This memo includes no request to IANA. 401 9. References 402 9.1. Normative References 404 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 405 STD 13, RFC 1034, November 1987. 407 [RFC1035] Mockapetris, P., "Domain names - implementation and 408 specification", STD 13, RFC 1035, November 1987. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 414 Names", BCP 32, RFC 2606, June 1999. 416 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 417 "DNS Extensions to Support IP Version 6", RFC 3596, 418 October 2003. 420 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 421 Architecture", RFC 4291, February 2006. 423 9.2. Informative References 425 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 426 Name System (DNS)", RFC 3833, August 2004. 428 [RBLDNS] Bernstein, D., "rbldns, in 'djbdns'". 430 [MAPSRBL] "MAPS RBL+". 432 [RBLDNSD] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs". 434 [SENDERBASE] 435 Ironport Systems, "Senderbase". 437 [KSN] Levine, J., "The South Korean Network Blocking List". 439 Appendix A. Change Log 441 *NOTE TO RFC EDITOR: This section may be removed upon publication of 442 this document as an RFC.* 444 A.1. Changes since -asrg-dnsbl-06 446 Change forbidden example from EXAMPLE to INVALID. 448 Remove SOA encoded email addresses. 450 Change IPv6 test addresses. 452 A.2. Changes since -asrg-dnsbl-05 454 Pervasive edits to standard language, including RFC2119 terms. 456 Test entries clarified for IPv4, invented for IPv6 and domains. 458 Author's Address 460 John Levine 461 Taughannock Networks 462 PO Box 727 463 Trumansburg, NY 14886 465 Phone: +1 831 480 2300 466 Email: standards@taugh.com 467 URI: http://www.taugh.com 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2008). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org.