idnits 2.17.00 (12 Aug 2021) /tmp/idnits54057/draft-eddy-ipv6-maturity-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 8, 2006) is 5850 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 information found for draft-eddy-ipv6-ipv4-comparison - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft Verizon Federal Network Systems 4 Expires: November 9, 2006 W. Ivancic 5 NASA Glenn Research Center 6 May 8, 2006 8 Assessment of IPv6 Maturity 9 draft-eddy-ipv6-maturity-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 9, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document collects and comments on several indicators of IPv6's 43 maturity level as a technology. This data can be used in decision- 44 making processes where many myths regarding IPv6 completeness and 45 deployability persist. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Protocol Documentation . . . . . . . . . . . . . . . . . . . 4 51 3. Running Code . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Real-World Deployment . . . . . . . . . . . . . . . . . . . 7 53 5. Policy Directives . . . . . . . . . . . . . . . . . . . . . 9 54 6. Summary of Findings . . . . . . . . . . . . . . . . . . . . 10 55 7. Security Considerations . . . . . . . . . . . . . . . . . . 11 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 57 9. Informative References . . . . . . . . . . . . . . . . . . . 12 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 59 Intellectual Property and Copyright Statements . . . . . . . 14 61 1. Introduction 63 While IPv4 has achieved widespread use and acclaim, its intended 64 successor, IPv6, is still facing some hurdles in large-scale 65 deployment. In both aeronautical networking and space networks a 66 move towards network-centric operations and away from application- 67 specific point-to-point links is occuring. In multiple groups that 68 are attempting to define aeronautical or space networking 69 architectures, the use of Internet protocols is well-accepted, but 70 there is considerable uncertainty on whether to use IPv4, IPv6, or a 71 dual-stack. 73 It is the technical opinion of many that IPv6 is favorable, due to 74 some of its features (mobility and security are particularly 75 important for network-centric operations). Vague notions persist 76 that IPv6 is still ephemeral work-in-progress and not yet ready for 77 widespread use, or that IPv6 has no market support. In this 78 document, we attempt to largely dispel these notions as myths by 79 presenting several sets of hard data that argue to the contrary. 80 Companion documents debunk arguments where IPv4 is brought forward as 81 a favored choice based on the logic that it has lower "overhead" than 82 IPv6 [Eddy06], and provide a comparison of the relative features of 83 IPv6 and IPv4 [EI06]. 85 This document is broken down as follows. Section 2 contains 86 discussion of the available specifications, their status as 87 standards, and other informational materials regarding IPv6. 88 Section 3 describes the availability of IPv6 support in common 89 products, operating systems, and commercial routers. Section 4 90 contains some information on real-world usage of IPv6 which is 91 currently happening, and Section 5 considers various policy 92 directives and guidance on deploying IPv6. Finally, Section 6 then 93 summarizes the results of this study. 95 2. Protocol Documentation 97 The IPv6 standard was the output of the IPng course of action to find 98 a replacement for IPv4, given all of the lessons learned from IPv4 99 use over the years. While many people have the notion that the 100 significance of IPv6 lies in a larger address space, an examination 101 of the literature shows that this is only the tip of the iceberg, and 102 the IPv4 address size was only one of around a dozen IPv4 aspects 103 that it was seen necessary to change. The search tool on the rfc- 104 editor.org website can be used to find many RFCs that document the 105 history of the IPng process, and archived copies of expired internet- 106 drafts with further details can also be found on the Internet. In 107 April of 2006, a simple search on rfc-editor.org for "IPng" yielded 108 41 RFC documents, most of which are Informational and contain inputs 109 to the IPng from representatives of various industry segments or 110 researchers. 112 In December of 1995, RFC 1883 was published as a Proposed Standard 113 for IPv6 [RFC1883]. Three years later, in December of 1998, RFC 2460 114 was published as a Draft Standard [RFC2460]. This basic 115 specification that covers the IPv6 header format, required extension 116 headers, fragmentation behavior, flow labels, traffic classes, and 117 upper-layer protocol issues has remained unchanged since its 118 publication. Accompanying documents that can be considered the core 119 of IPv6 include the specifications for ICMPv6 [RFC2463], Neighbor 120 Discovery [RFC2461], and Address Autoconfiguration [RFC2462], all of 121 which have reached the Draft Standard level as well. Many protocols 122 that are well-accepted by industry and in widespread use are only 123 Proposed Standards, and not even formally at this level of maturity 124 in the IETF process. All of this demonstrates that the core IPv6 125 specification is agreed upon and stable and has been for some time 126 now. 128 Additionally, a very rough search on the rfc-editor.org website for 129 "IPv6", turns up 166 documents. For the most part, these document 130 IPv6 usage and interactions in conjunction with other protocols, or 131 extensions to IPv6. This search is fairly conservative in that a 132 much larger number of documents deal with IPv6 in at least some way, 133 but are not indexed under the term "IPv6", and so do not turn up. We 134 simply use the large number of results that do show up as evidence 135 that integration of IPv6 with numerous link layers and extension of 136 IPv6 has been actively pursued in industry, and a large number of 137 supplementary standards have been produced. Among IETF working 138 groups, the "Mobility for IPv4" group seems to be the only one 139 specifically chartered to provide an IPv4-only protocol, whereas at 140 least 8 others are chartered specifically to provide IPv6-based 141 solutions, including: 143 o IPv6 over Low-Power WPAN (6lowpan) 145 o IPv6 Working Group (ipv6) 147 o Mobility for IPv6 (mip6) 149 o Mobile IPv6 Signalling and Handoff Optimization (mipshop) 151 o Mobile Nodes and Multiple Interfaces in IPv6 (monami6) 153 o Site Multihoming by IPv6 Intermediation (shim6) 155 o Site Multihoming in IPv6 (multi6) 157 o IPv6 Operations (v6ops) 159 Among other working groups, for example those focusing on security, 160 application, or transport protocols, it seems that the vast majority 161 are constructing protocols that will work with either IPv6 or both 162 IPv6 and IPv4 (e.g. Host Identity Protocol). There is a clear sense 163 of support for IPv6 in the standards community based on this survey 164 of current IETF activities. From mailing list archives it can be 165 seen that representatives from several large vendors and operators 166 are active participants in the IPv6 groups, not merely academics. 168 In addition to the IETF, other bodies exist, such as the IPv6 Forum, 169 to further the use and adoption of IPv6, and produce documentation 170 and reccommendations on the topic. There are widely available 171 training courses and materials, textbooks, and support services for 172 IPv6 deployment, transition, and troubleshooting. A search on 173 amazon.com for IPv6 books turned up 60 results. The next section of 174 this document examines actual IPv6 implementations that are readily 175 available. 177 3. Running Code 179 A large number of IPv6 implementations are available from both 180 commercial vendors and the open-source community. The IPv6 Forum has 181 created the "IPv6 Ready" Logo Program which consists of sets of 182 criteria that can be used to assess the features and interoperability 183 of IPv6 products. Phase-1 of this program judges implementations of 184 basic or core IPv6 functions. Over 200 products have been certified 185 to use the Phase-1 IPv6 Ready Logo. The Phase-2 Logo builds upon 186 Phase-1 by adding tests for IPsec and mobility features. Several 187 dozen products are on the approved list for Phase-2. 189 Major router vendors are serious about IPv6 and provide products that 190 implement many advanced features in addition to the IPv6 base. 191 Cisco, for instance, has a webpage that lists dozens of specific IPv6 192 services and details which versions of their IOS software implement 193 the features and where documentation on configuring them can be found 194 (http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/ 195 products_configuration_guide_chapter09186a00801d65ed.html). 196 Similarly, Juniper has supported IPv6 basic functions since 2001 in 197 JUNOS 5.1 [Shimizu01], and supports IPv6 across their product line 198 [Uze02]. 200 IPv6 support is built into many off-the-shelf end-host operating 201 systems as well. Microsoft's Windows Server 2003, Windows XP 202 (Service Pack 1 or 2), and Windows CE .NET all support IPv6. Apple's 203 MacOS 10.3 and Sun's Solaris 8 similarly have built-in support for 204 IPv6. The Japanese KAME project developed IPv6 support for the open- 205 source BSD-based operating systems, and Linux has had IPv6 support 206 since the 2.2 kernel. 208 Additionally, many common consumer devices come with IPv6. For 209 instance, the 3GPP and 3GPP2 cellular telephony groups have made IPv6 210 a part of the IP Multimedia System (IMS). IPv6 capable, or dual- 211 stack cellular handsets have been available for some time (the Nokia 212 7700 is an example), and a dual-stack takes up only about 15% more 213 space on the device than an IPv4-only stack [Loughney04]. Sony's 214 Playstation 2 and Microsoft's X-Box video game consoles are both 215 IPv6-enabled and widely deployed. 217 4. Real-World Deployment 219 In this section, we examine evidence that the IPv6 Internet is 220 currently operational. This evidence comes from four main sources 221 (1) known IPv6 exchanges and peering services, (2) reports from the 222 RIRs on IPv6 allocations, (3) BGP announcements, and (4) measurements 223 of 6-to-4 gateways. All of this evidence suggests that IPv6 is 224 nearing a critical mass of operational use. 226 The www.v6nap.net web site lists 18 exchanges that support IPv6 227 throughout the United States, South Korea, the Netherlands, Finland, 228 France, Germany, Japan and the UK. As an example, the MAE exchange 229 (operated by Verizon Business) is really a number of facilities 230 consisting of four main locations in the United States, one in Paris, 231 France, and one in Frankfurt, Germany. Each of these facilities may 232 actually extend to a number of physical sites throughout a number of 233 nearby cities. A customer's routers connect to switches at a MAE 234 site over which they can interface with other customer's routers to 235 exchange traffic. Currently, all of the MAE facilities are capable 236 of exchanging IPv6 traffic. The same switches are used to support 237 both IPv4 and IPv6, accros a number of access types (ATM, Frame 238 Relay, or Gigabit Ethernet). Native IPv6, dual-stack, and tunneled 239 connections are supported at the customer's discretion. New IPv6 240 native exchange point addresses are available upon request from MAE, 241 and IPv6 addresses are automatically provided to customers with 242 current IPv4 addresses at an exchange. More information can be found 243 at www.mae.net. 245 IPv6 address blocks are assigned by IANA to the five Regional 246 Internet Registries (RIRs). The RIRs then further distribute smaller 247 blocks of addresses to IPv6 ISPs and other Local Internet Registries 248 (LIRs). Each of the five RIRs publishes some statistics on the 249 prefixes that they have delegated. Examination of some recent 250 reports of these statistics allows us to count the number of IPv6 251 prefixes delegated, as well as the Autonomous System Numbers (ASNs) 252 assigned (note that the percentage presented that compares the number 253 of IPv6 prefixes to the number of ASNs is not a completely valid way 254 to measure IPv6 adoption for a number of reasons): 256 AfriNIC (April 24, 2006): 11 IPv6 prefixes (220 ASNs - 5%) 258 APNIC (April 24, 2006): 436 IPv6 prefixes (2162 ASNs - 20.2%) 260 ARIN (April 24, 2006): 247 IPv6 prefixes (16729 ASNs - 1.5%) 262 LACNIC (April 21, 2006): 54 IPv6 prefixes (1060 ASNs - 5.1%) 263 RIPE NCC (April 21, 2006): 761 IPv6 prefixes (11437 ASNs - 6.7%) 265 This data indicates that IPv6 addresses have been assigned to a fair 266 number of LIRs, especially in the Asia-Pacific region. The current 267 policies for IPv6 allocation from the RIRs do not allow address 268 blocks to be assigned to end-sites (although this may be changed 269 soon), whereas this is not the case in IPv4, so the number of ASNs 270 reflects a number of IPv4 end-sites that are not eligible for IPv6 271 address blocks from an RIR, and thus the number of locations where 272 IPv6 is usable is actually much greater than the percentages of 273 prefixes over ASNs reported here. If Provider Independent addressing 274 for IPv6 became popular with the RIRs, then we would expect these 275 percentages to more accurately reflect the penetration of IPv6. 276 Since ASNs may correspond to multiple prefixes, at full adoption, 277 these would go somewhere above 100%. 279 In April of 2006, Geoff Huston's BGP analysis tool (bgp.potaroo.net/ 280 v6/as6447) sshows between 721 active IPv6 BGP entries. Among these, 281 589 unique AS numbers appear, with 419 origin-only ASes, 12 transit- 282 only ASes, and the remainder mixed. These BGP observations show that 283 there is a global IPv6 routing table with a reasonable number of 284 sites contained in it. 286 6-to-4 [RFC3056] is a transition mechanism that tunnels IPv6 over 287 IPv4 packets for transit across the network. Pekka Savola has 288 studied the traffic at a public 6-to-4 gateway [Savola04]. This was 289 only considered to be a relatively small, or lightly-used, 6-to-4 290 gateway, it still was probed by 2 million Windows hosts, and actively 291 used by over 1000 nodes per month in 2004. DNS traffic, as well as 292 SSH, HTTP, SMTP, and BitTorrent file sharing were all observed over 293 the 6-to-4 gateway, indicating that typical Internet applications are 294 functioning over it. 296 5. Policy Directives 298 Among US government agencies, the Department of Defense (DoD) was an 299 early recognizer of the benefits of IPv6 and began the deployment and 300 transition process before most other federal agencies even considered 301 IPv6. the DoD has a number of useful resources for IPv6, including a 302 set of feature profiles for judging aquisitions against [Green05]. 303 The DoD has announced plans to fully transition to IPv6 by fiscal 304 year 2008. 306 In 2005, the Government Accountability Office (GAO) recomended to the 307 Office of Management and Budget (OMB) that other federal agencies 308 should follow DoD's lead and begin planning for a move to IPv6 309 [GAO05]. Following this, it was announced that June 2008 was the 310 deadline for all agencies to support IPv6 in their operational 311 networks [Evans05]. 313 Plans for the 2008 Olympics in China involve IPv6 as a prominent 314 means of connecting millions of users to various types of multimedia 315 content [Chi-Loong05]. In general, the growth in the "online 316 population" in Asian countries is causing IPv6 to be eager to deploy 317 IPv6. 319 Since IPv6 several of the features of IPv6 can be back-ported or 320 hacked into an IPv4 architecute through various means, IPv6 has been 321 portrayed as unecessary or lacking a killer-application by many 322 pundits. That these opinions are not very well informed from a 323 standpoint of network architecture, where attempting to make IPv4 do 324 things that it was not designed for make the network more fragile. 325 For instance, the use of NAT to get around addressing limitations in 326 IPv4 is well-known to have poor architectural implications [RFC2993]. 327 Unfortunately, US businesses still seem to be stalling on IPv6 328 deployment, however, the recent government action in this area may 329 serve to motivate the private sector to some extent. 331 6. Summary of Findings 333 The general result of this study is that IPv6 can be used at the 334 present time, and is being deployed in diverse settings (from mobile 335 phones and video games to government systems). 337 The technical advantages, ease of availability, and policy directives 338 regarding IPv6 combine to make it the strongly favored option for use 339 in present network design efforts. 341 7. Security Considerations 343 This informational document only contains data about IPv6 maturity. 344 There are no new security considerations raised by this material. 346 8. Acknowledgements 348 Work on this document was performed at NASA's Glenn Research Center, 349 in support of the NASA Space Communications Architecture Working 350 Group (SCAWG), and the FAA/Eurocontrol Future Communications Study 351 (FCS). Joe Ishac of NASA contributed useful comments on this 352 document. 354 9. Informative References 356 [Chi-Loong05] 357 Chi-Loong, C., "China's IT Gold", CMPnetAsia Newsletter , 358 December 2005. 360 [EI06] Eddy, W. and J. Ishac, "IPv6-IPv4 Feature Comparison", 361 draft-eddy-ipv6-ipv4-comparison-00 Internet-Draft (work in 362 progress), May 2006. 364 [Eddy06] Eddy, W., "Comparison of IPv4 and IPv6 Header Overhead", 365 draft-eddy-ipv6-overhead-00 Internet-Draft (work in 366 progress), May 2006. 368 [Evans05] Evans, K., "Transition Planning for Internet Protocol 369 Version 6", Office of Management and Budget, Memorandum 370 for the Chief Information Officers M-05-22, August 2005. 372 [GAO05] GAO, "Federal Agencies Need to Plan for Transition and 373 Manage Security Risks", GAO report to congressional 374 requesters GAO-05-471, May 2005. 376 [Green05] Green, D., "DoD IPv6 Standard Profiles for IPv6 Capable 377 Products", DISA draft for coordination, Draft v.06, 378 December 2005. 380 [Loughney04] 381 Loughney, J., "IPv6 in 2G and 3G Networks", North American 382 IPv6 Summit 2004, June 2004. 384 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 385 (IPv6) Specification", RFC 1883, December 1995. 387 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 388 (IPv6) Specification", RFC 2460, December 1998. 390 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 391 Discovery for IP Version 6 (IPv6)", RFC 2461, 392 December 1998. 394 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 395 Autoconfiguration", RFC 2462, December 1998. 397 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 398 Protocol (ICMPv6) for the Internet Protocol Version 6 399 (IPv6) Specification", RFC 2463, December 1998. 401 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 402 November 2000. 404 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 405 via IPv4 Clouds", RFC 3056, February 2001. 407 [Savola04] 408 Savola, P., "Observations of IPv6 Traffic on a 6to4 409 Relay", ACM Computer Communication Review, Volume 35, 410 Number 1, January 2005. 412 [Shimizu01] 413 Shimizu, T., "Juniper Networks IPv6 Implementation", 414 Global IPv6 Summit, Yokohama, Japan, December 2001. 416 [Uze02] Uze, J., "Juniper IPv6 Solution", RIPE 42, IPv6 WG, 417 May 2002. 419 Authors' Addresses 421 Wesley M. Eddy 422 Verizon Federal Network Systems 423 21000 Brookpark Rd, MS 54-5 424 Cleveland, OH 44135 426 Phone: 216-433-6682 427 Email: weddy@grc.nasa.gov 429 William D. Ivancic 430 NASA Glenn Research Center 431 21000 Brookpark Rd, MS 54-5 432 Cleveland, OH 44135 434 Phone: 216-433-3494 435 Email: wivancic@grc.nasa.gov 437 Intellectual Property Statement 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Disclaimer of Validity 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Copyright Statement 473 Copyright (C) The Internet Society (2006). This document is subject 474 to the rights, licenses and restrictions contained in BCP 78, and 475 except as set forth therein, the authors retain all their rights. 477 Acknowledgment 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.