idnits 2.17.1 draft-ietf-v6ops-scanning-implications-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 23, 2006) is 6396 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 informational reference (is this intentional?): RFC 2460 (ref. '1') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '2') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '5') (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-security-overview-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Expires: April 26, 2007 October 23, 2006 6 IPv6 Implications for Network Scanning 7 draft-ietf-v6ops-scanning-implications-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The 128 bits of IPv6 address space is considerably bigger than the 32 41 bits of address space of IPv4. In particular, the IPv6 subnets to 42 which hosts attach will by default have 64 bits of host address 43 space. As a result, traditional methods of remote TCP or UDP network 44 scanning to discover open or running services on a host will 45 potentially become far less feasible, due to the larger search space 46 in the subnet. In addition automated attacks, such as those 47 performed by network worms, may be hampered. This document discusses 48 this property of IPv6, and describes related issues for site 49 administrators of IPv6 networks to consider, which may be of 50 importance when planning site address allocation and management 51 strategies. While traditional network scanning probes (whether by 52 individuals or automated via network worms) may become less common, 53 administrators should be aware of other methods attackers may use to 54 discover IPv6 addresses on a target network, and be aware of 55 appropriate measures to mitigate these. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Target Address Space for Network Scanning . . . . . . . . . . 4 61 2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Reducing the IPv6 Search Space . . . . . . . . . . . . . . 4 64 2.4. Dual-stack Networks . . . . . . . . . . . . . . . . . . . 5 65 2.5. Defensive Scanning . . . . . . . . . . . . . . . . . . . . 5 66 3. Alternatives for Attackers . . . . . . . . . . . . . . . . . . 5 67 3.1. On-link Methods . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Multicast or Other Service Discovery . . . . . . . . . . . 6 69 3.3. Log File Analysis . . . . . . . . . . . . . . . . . . . . 6 70 3.4. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 6 71 3.5. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 7 72 3.6. Application Participation . . . . . . . . . . . . . . . . 7 73 3.7. Transition Methods . . . . . . . . . . . . . . . . . . . . 7 74 4. Site Administrator Tools . . . . . . . . . . . . . . . . . . . 7 75 4.1. IPv6 Privacy Addresses . . . . . . . . . . . . . . . . . . 8 76 4.2. DHCP Service Configuration Options . . . . . . . . . . . . 8 77 4.3. Rolling Server Addresses . . . . . . . . . . . . . . . . . 8 78 4.4. Application-Specific Addresses . . . . . . . . . . . . . . 9 79 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 Intellectual Property and Copyright Statements . . . . . . . . . . 12 87 1. Introduction 89 One of the key differences between IPv4 and IPv6 is the much larger 90 address space for IPv6, which also goes hand-in-hand with much larger 91 subnet sizes. This change has a significant impact on the 92 feasibility of TCP and UDP network scanning, whereby an automated 93 process is run to detect open ports (services) on systems that may 94 then be subject of a subsequent attack. Today many IPv4 sites are 95 subjected to such probing on a recurring basis. 97 The 128 bits of IPv6 [1] address space is considerably bigger than 98 the 32 bits of address space in IPv4. In particular, the IPv6 99 subnets to which hosts attach will by default have 64 bits of host 100 address space [3]. As a result, traditional methods of remote TCP or 101 UDP network scanning to discover open or running services on a host 102 will potentially become far less feasible, due to the larger search 103 space in the subnet. This document discusses this property of IPv6, 104 and describes related issues for site administrators of IPv6 networks 105 to consider, which may be of importance when planning site address 106 allocation and management strategies. 108 This document complements the transition-centric discussion of the 109 issues that can be found in Appendix A of the IPv6 Transition/ 110 Co-existence Security Considerations [7] text, which takes a broad 111 view of security issues for transitioning networks. 113 The reader is also referred to a recent paper by Bellovin on worm 114 propogation strategies in IPv6 networks [8]. This paper discusses 115 some of the issues included in this document, from a slightly 116 different perspective. 118 Network scanning is quite a prevalent tactic used by would-be 119 attackers. There are two general classes of such scanning. In one 120 case, the probes are from an attacker outside a site boundary who is 121 trying to find weaknesses on any system in that network which they 122 may then subsequently be able to compromise. The other case is 123 scanning by worms that spread through (site) networks, looking for 124 further hosts to compromise. Many worms, like Slammer, rely on such 125 address scanning methods to propagate, whether they pick subnets 126 numerically (and thus probably topologically) close to the current 127 victim, or subnets in random remote networks. 129 It must be remembered that the defence of a network must not rely 130 solely on the obscurity of the hosts on that network. Such a feature 131 or property is only one measure in a set of measures that may be 132 applied. However, with a growth in usage of IPv6 devices in open 133 networks likely, and security becoming more likely an issue for the 134 end devices, such obfuscation can be useful where its use is of 135 little or no cost to the administrator to implement it. However, a 136 law of diminuishing returns does apply. An administrator who 137 undertakes an address hiding policy should be aware that while IPv6 138 host addresses may be picked that are likely to take significant time 139 to discover by traditional scanning methods, there are other means by 140 which such addresses may be discovered. Implementing all of them may 141 be deemed unwarranted effort. But it is up to the site administrator 142 to be aware of the context and the options available, and in 143 particular what new methods may attackers use to glean IPv6 address 144 information, and how these can potentially be mitigated against. 145 This document is intended to be informational; there is not yet 146 sufficient deployment experience for it to be considered BCP. 148 2. Target Address Space for Network Scanning 150 There are significantly different considerations for the feasibility 151 of plain, brute force IPv4 and IPv6 address scanning. 153 2.1. IPv4 155 A typical IPv4 subnet may have 8 bits reserved for host addressing. 156 In such a case, a remote attacker need only probe at most 256 157 addresses to determine if a particular service is running publicly on 158 a host in that subnet. Even at only one probe per second, such a 159 scan would take under 5 minutes to complete. 161 2.2. IPv6 163 A typical IPv6 subnet will have 64 bits reserved for host addressing. 164 In such a case, a remote attacker in principle needs to probe 2^64 165 addresses to determine if a particular open service is running on a 166 host in that subnet. At a very conservative one probe per second, 167 such a scan may take some 5 billion years to complete. A more rapid 168 probe will still be limited to (effectively) infinite time for the 169 whole address space. However, there are ways for the attacker to 170 reduce the address search space to scan against within the target 171 subnet, as we discuss below. 173 2.3. Reducing the IPv6 Search Space 175 The IPv6 host address space through which an attacker may search can 176 be reduced in at least two ways. 178 First, the attacker may rely on the administrator conveniently 179 numbering their hosts from [prefix]::1 upward. This makes scanning 180 trivial, and thus should be avoided unless the host's address is 181 readily obtainable from other sources (for example it is the site's 182 primary DNS or email MX server). Alternatively if hosts are numbered 183 sequentially, or using any regular scheme, knowledge of one address 184 may expose other available addresses to scan. 186 Second, in the case of statelessly autoconfiguring [1] hosts, the 187 host part of the address will take a well-known format that includes 188 the Ethernet vendor prefix and the "fffe" stuffing. For such hosts, 189 the search space can be reduced to 48 bits. Further, if the Ethernet 190 vendor is also known, the search space may be reduced to 24 bits, 191 with a one probe per second scan then taking a less daunting 194 192 days. Even where the exact vendor is not known, using a set of 193 common vendor prefixes can reduce the search. In addition, many 194 nodes in a site network may be procured in batches, and thus have 195 sequential or near sequential MAC addresses; if one node's 196 autoconfigured address is known, scanning around that address may 197 yield results for the attacker. Again, any form of sequential host 198 addressing should be avoided if possible. 200 2.4. Dual-stack Networks 202 Full advantage of the increased IPv6 address space in terms of 203 resilience to network scanning may not be gained until IPv6-only 204 networks and devices become more commonplace, given that most IPv6 205 hosts are currently dual stack, with (more readily scannable) IPv4 206 connectivity. However, many applications or services (e.g. new peer- 207 to-peer applications) on the (dual stack) hosts may emerge that are 208 only accessible over IPv6, and that thus can only be discovered by 209 IPv6 address scanning. 211 2.5. Defensive Scanning 213 The problem faced by the attacker for an IPv6 network is also faced 214 by a site administrator looking for vulnerabilities in their own 215 network's systems. The administrator should have the advantage of 216 being on-link for scanning purposes though. 218 3. Alternatives for Attackers 220 If IPv6 hosts in subnets are allocated addresses 'randomly', and as a 221 result IPv6 network scanning becomes relatively infeasible, attackers 222 will need to find new methods to identify IPv6 addresses for 223 subsequent scanning. In this section, we discuss some possible paths 224 attackers may take. In these cases, the attacker will attempt to 225 identify specific IPv6 addresses for subsequent targeted probes. 227 3.1. On-link Methods 229 If the attacker is on link, then traffic on the link, be it Neighbor 230 Discovery or application based traffic, can invariably be observed, 231 and target addresses learnt. In this document we are assuming the 232 attacker is off link, but traffic to or from other nodes (in 233 particular server systems) is likely to show up if an attacker can 234 gain a presence on any one subnet in a site's network. 236 IPv6-enabled hosts on local subnets may be discovered through probing 237 the "all hosts" link local multicast address. Likewise any routers 238 on link may be found via the "all routers" link local multicast 239 address. 241 Where a host has already been compromised, its Neighbor Discovery 242 cache is also likely to include information about active nodes on 243 link, just as an ARP cache would do for IPv4. 245 3.2. Multicast or Other Service Discovery 247 A site may also have site or organisational scope multicast 248 configured, in which case application traffic, or service discovery, 249 may be exposed site wide. An attacker may choose to use any other 250 service discovery methods supported by the site. 252 There are also issues with disclosure from multicast itself. Where 253 an Embedded RP [6] multicast group address is known, the unicast 254 address of the rendezvous point is implied by the group address. 255 Where unicast prefix based multicast group addresses [4] are used, 256 specific /64 link prefixes may also be disclosed. 258 3.3. Log File Analysis 260 IPv6 addresses may be harvested from recorded logs such as web site 261 logs. Anywhere else where IPv6 addresses are explicitly recorded may 262 prove a useful channel for an attacker, e.g. by inspection of the 263 (many) Received from: or other header lines in archived email or 264 Usenet news messages. 266 3.4. DNS Advertised Hosts 268 Any servers that are DNS listed, e.g. MX mail relays, or web 269 servers, will remain open to probing from the very fact that their 270 IPv6 addresses will be published in the DNS. Where a site uses 271 sequential host numbering, publishing just one address may lead to a 272 threat upon the other hosts. 274 Sites may use a two-faced DNS where internal system DNS information 275 is only published in an internal DNS. It is also worth noting that 276 the reverse DNS tree may also expose address information. 278 3.5. DNS Zone Transfers 280 In the IPv6 world a DNS zone transfer is much more likely to narrow 281 the number of hosts an attacker needs to target. This implies 282 restricting zone transfers is (more) important for IPv6, even if it 283 is already good practice to restrict them in the IPv4 world. 285 3.6. Application Participation 287 More recent peer-to-peer applications often include some centralised 288 server which coordinates the transfer of data between peers. The 289 BitTorrent application builds swarms of nodes that exchange chunks of 290 files, with a tracker passing information about peers with available 291 chunks of data between the peers. Such applications may offer an 292 attacker a source of peer IP addresses to probe. 294 3.7. Transition Methods 296 Specific knowledge of the target network may be gleaned if that 297 attacker knows it is using 6to4, ISATAP, Teredo, or other techniques 298 that derive low-order bits from IPv4 addresses (though in this case, 299 unless they are using IPv4 NAT, the IPv4 addresses may be probed 300 anyway). For example, the current Microsoft 6to4 implementation uses 301 the address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD 302 implementations default to 2002:V4ADDR::1. This leads to specific 303 knowledge of specific hosts in the network. Given one host in the 304 network is observed as using a given transition technique, it is 305 likely that there are more. 307 4. Site Administrator Tools 309 There are some tools that site administrators can apply to make the 310 task for IPv6 network scanning attackers harder. These methods arise 311 from the considerations in the previous section. 313 The author notes that at his current (university) site, there is no 314 evidence of general network scanning running across subnets. 315 However, there is network scanning over IPv6 connections to systems 316 whose IPv6 addresses are advertised (DNS servers, MX relays, web 317 servers, etc), which are presumably looking for other open ports on 318 these hosts to probe. 320 4.1. IPv6 Privacy Addresses 322 By using the IPv6 Privacy Extensions [2] hosts in a network may only 323 be able to connect to external systems using their current 324 (temporary) privacy address. While an attacker may be able to port 325 scan that address if they do so quickly upon observing or otherwise 326 learning of the address, the threat or risk is reduced due to the 327 time-constrained value of the address. One implementation of RFC3041 328 already deployed has privacy addresses active for one day, with such 329 addresses reachable for seven days. 331 Note that an RFC3041 host will usually also have a separate static 332 global IPv6 address by which it can also be reached, and that may be 333 DNS-advertised if an externally reachable service is running on it. 335 The implication is that while Privacy Addresses can mitigate the 336 long-term value of harvested addresses, an attacker creating an IPv6 337 application server to which clients connect will still be able to 338 probe the clients by their Privacy Address as and when they visit 339 that server. In the general context of hiding the addresses exposed 340 from a site, an administrator may choose to use IPv6 Privacy 341 Addresses. The duration for which these are valid will impact on the 342 usefulness of such observed addresses to an external attacker. The 343 frequency with which such address get recycled could be increased, 344 though this will present the site administrator with more addresses 345 to track the usage of. 347 It may be worth exploring whether firewalls can be adapted to allow 348 the option to block traffic initiated to a known IPv6 Privacy Address 349 from outside a network boundary. While some applications may 350 genuinely require such capability, it may be useful to be able to 351 differentiate in some circumstances. 353 4.2. DHCP Service Configuration Options 355 The administrator should configure DHCPv6 so that the first addresses 356 allocated from the pool begins much higher in the address space than 357 at [prefix]::1. DHCPv6 also includes an option to use Privacy 358 Extension [2] addresses, i.e. temporary addresses, as described in 359 Section 12 of the DHCPv6 [5] specification. It is desirable that 360 allocated addresses are not sequential, nor have any predictable 361 pattern to them. 363 4.3. Rolling Server Addresses 365 Given the huge address space in an IPv6 subnet/link, and the support 366 for IPv6 multiaddressing, whereby a node or interface may have 367 multiple IPv6 valid addresses of which one is preferred for sending, 368 it may be possible to periodically change the advertised addresses 369 that certain long standing services use (where 'short' exchanges to 370 those services are used). 372 For example, an MX server could be assigned a new primary address on 373 a weekly basis, and old addresses expired monthly. Where MX server 374 IP addresses are detected and cached by spammers, such a defence may 375 prove useful to reduce spam volumes, especially as such IP lists may 376 also be passed between potential attackers for subsequent probing. 378 4.4. Application-Specific Addresses 380 By a similar reasoning, it may be possible to consider using 381 application-specific addresses for systems, such that a given 382 application may have exclusive use of an address, meaning that 383 disclosure of the address should not expose other applications or 384 services running on the same system. 386 5. Conclusions 388 Due to the much larger size of IPv6 subnets in comparison to IPv4 it 389 will become less feasible for network scanning methods to detect open 390 services for subsequent attacks. If administrators number their IPv6 391 subnets in 'random', non-predictable ways, attackers, whether they be 392 in the form of automated network scanners or dynamic worm 393 propagation, will need to use new methods to determine IPv6 host 394 addresses to target. Of course, if those systems are dual-stack, and 395 have open IPv4 services running, they will remain exposed to 396 traditional probes over IPv4 transport. 398 This document has discussed the considerations a site administrator 399 should bear in mind when considering IPv6 address planning issues and 400 configuring various service elements. It highlights relevant issues 401 and offers some informational guidance for administrators. While 402 some suggestions are currently more practical than others, it is up 403 to individual administrators to determine how much effort they wish 404 to invest in 'address hiding' schemes, given that this is only one 405 aspect of network security, and certainly not one to rely solely on. 406 But by implementing the basic principle of allocating 'random', non 407 predictable addresses, some level of obfuscation can be cheaply 408 deployed. 410 6. Security Considerations 412 There are no specific security considerations in this document 413 outside of the topic of discussion itself. 415 7. IANA Considerations 417 There are no IANA considerations for this document. 419 8. Acknowledgements 421 Thanks are due to people in the 6NET project for discussion of this 422 topic, including Pekka Savola, Christian Strauf and Martin Dunmore, 423 as well as other contributors from the IETF v6ops mailing list, 424 including Tony Finch, David Malone and Fred Baker. 426 9. Informative References 428 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 429 Specification", RFC 2460, December 1998. 431 [2] Narten, T. and R. Draves, "Privacy Extensions for Stateless 432 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 434 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 435 Autoconfiguration", RFC 2462, December 1998. 437 [4] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast 438 Addresses", RFC 3306, August 2002. 440 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 441 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 442 RFC 3315, July 2003. 444 [6] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) 445 Address in an IPv6 Multicast Address", RFC 3956, November 2004. 447 [7] Davies, E., "IPv6 Transition/Co-existence Security 448 Considerations", draft-ietf-v6ops-security-overview-05 (work in 449 progress), September 2006. 451 [8] Bellovin, S. et al, "Worm Propagation Strategies in an IPv6 452 Internet (http://www.cs.columbia.edu/~smb/papers/v6worms.pdf)", 453 ;login:, February 2006. 455 Author's Address 457 Tim Chown 458 University of Southampton 459 Southampton, Hampshire SO17 1BJ 460 United Kingdom 462 Email: tjc@ecs.soton.ac.uk 464 Intellectual Property Statement 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 493 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 494 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 495 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 500 Copyright (C) The Internet Society (2006). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society.