idnits 2.17.1 draft-eastlake-fnv-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 207 has weird spacing: '...ed char hash...' -- The document date (October 6, 2014) is 3482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 207, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Glenn Fowler 2 INTERNET-DRAFT Google 3 Intended Status: Informational Landon Curt Noll 4 Cisco Systems 5 Kiem-Phong Vo 6 Google 7 Donald Eastlake 8 Huawei Technologies 9 Expires: April 5, 2015 October 6, 2014 11 The FNV Non-Cryptographic Hash Algorithm 12 14 Abstract 16 FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with 17 good dispersion. The purpose of this document is to make information 18 on FNV and open source code performing FNV conveniently available to 19 the Internet community. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the authors. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 48 2. FNV Basics..............................................4 49 2.1 FNV Primes.............................................4 50 2.2 FNV offset_basis.......................................5 51 2.3 FNV Endianism..........................................5 53 3. Other Hash Sizes and XOR Folding........................6 54 4. FNV Constants...........................................7 56 5. The Source Code.........................................9 57 5.1 FNV-1a Code............................................9 58 5.1.1 FNV32 Code...........................................9 59 5.1.2 FNV64 C Code.........................................9 60 5.1.3 FNV128 Code..........................................9 61 5.1.4 FNV256 C Code........................................9 62 5.1.5 FNV512 C Code........................................9 63 5.1.6 FNV1024 C Code......................................10 64 5.2 FNV Test Code.........................................10 66 6. Security Considerations................................11 67 6.1 Why is FNV Non-Cryptographic?.........................11 69 7. IANA Considerations....................................12 70 Acknowledgements..........................................12 72 Normative References......................................13 73 Informative References....................................13 75 Appendix A: Work Comparison with SHA-1....................14 76 Appendix B: Previous IETF Reference to FNV................15 77 Appendix C: A Few Test Vectors............................16 79 Appendix Z: Change Summary................................17 80 Author's Address..........................................19 82 1. Introduction 84 The FNV hash algorithm is based on an idea sent as reviewer comments 85 to the [IEEE] POSIX P1003.2 committee by Glenn Fowler and Phong Vo in 86 1991. In a subsequent ballot round Landon Curt Noll suggested an 87 improvement on their algorithm. Some people tried this hash and found 88 that it worked rather well. In an EMail message to Landon, they named 89 it the "Fowler/Noll/Vo" or FNV hash. [FNV] 91 FNV hashes are designed to be fast while maintaining a low collision 92 rate. The high dispersion of the FNV hashes makes them well suited 93 for hashing nearly identical strings such as URLs, hostnames, 94 filenames, text, IP addresses, etc. Their speed allows one to quickly 95 hash lots of data while maintaining a reasonably low collision rate. 96 However, they are generally not suitable for cryptographic use. (See 97 Section 6.1.) 99 The FNV hash is widely used, for example in DNS servers, the Twitter 100 service, database indexing hashes, major web search / indexing 101 engines, netnews history file Message-ID lookup functions, anti-spam 102 filters, a spellchecker programmed in Ada 95, flatassembler's open 103 source x86 assembler - user-defined symbol hashtree, non- 104 cryptographic file fingerprints, computing Unique IDs in DASM (DTN 105 Applications for Symbian Mobile-phones), Microsoft's hash_map 106 implementation for VC++ 2005, the realpath cache in PHP 5.x 107 (php-5.2.3/TSRM/tsrm_virtual_cwd.c), and many other uses. 109 A study has recommended FNV in connetion with the IPv6 Flow Label 110 field [IPv6flow]. 112 FNV hash algorithms and source code have been released into the 113 public domain. The authors of the FNV algorithm took deliberate steps 114 to disclose the algorithm in a public forum soon after it was 115 invented. More than a year passed after this public disclosure and 116 the authors deliberately took no steps to patent the FNV algorithm. 117 Therefore, it is safe to say that the FNV authors have no patent 118 claims on the FNV algorithm as published. 120 If you use an FNV function in an application, you are kindly 121 requested to send an EMail about it to: fnv-mail@asthe.com 123 2. FNV Basics 125 This document focuses on the FNV-1a function whose pseudo-code is as 126 follows: 128 hash = offset_basis 129 for each octet_of_data to be hashed 130 hash = hash xor octet_of_data 131 hash = hash * FNV_Prime 132 return hash 134 In the pseudo-code above, hash is a power-of-two number of bits (32, 135 64, ... 1024) and offset_basis and FNV_Prime depend on the size of 136 hash. 138 The FNV-1 algorithm is the same, including the values of offset_basis 139 and FNV_Prime, except that the order of the two lines with the "xor" 140 and multiply operations are reversed. Operational experience 141 indicates better hash dispersion for small amounts of data with 142 FNV-1a. FNV-0 is the same as FNV-1 but with offset_basis set to zero. 143 FNV-1a is suggested for general use. 145 2.1 FNV Primes 147 The theory behind FNV_Prime's is beyond the scope of this document 148 but the basic property to look for is how an FNV_Prime would impact 149 dispersion. Now, consider any n-bit FNV hash where n is >= 32 and 150 also a power of 2. For each such an n-bit FNV hash, an FNV_Prime p is 151 defined as: 153 When s is an integer and 4 < s < 11, then FNV_Prime is the 154 smallest prime p of the form: 156 256**int((5 + 2^s)/12) + 2**8 + b 158 where b is an integer such that: 160 0 < b < 2**8 161 The number of one-bits in b is 4 or 5 163 and where p mod (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7). 165 Experimentally, FNV_Primes matching the above constraints tend to 166 have better dispersion properties. They improve the polynomial 167 feedback characteristic when an FNV_Prime multiplies an intermediate 168 hash value. As such, the hash values produced are more scattered 169 throughout the n-bit hash space. 171 The case where s < 5 is not considered because the resulting hash 172 quality is too low. Such small hashes can, if desired, be derived 173 from a 32 bit FNV hash by XOR folding (see Section 3). The case where 174 s > 10 is not considered because of the doubtful utility of such 175 large FNV hashes and because the criteria for such large FNV_Primes 176 is more complex, due to the sparsity of such large primes, and would 177 needlessly clutter the criteria given above. 179 Per the above constraints, an FNV_Prime should have only 6 or 7 one- 180 bits in it. Therefore, some compilers may seek to improve the 181 performance of a multiplication with an FNV_Prime by replacing the 182 multiplication with shifts and adds. However, note that the 183 performance of this substitution is highly hardware-dependent and 184 should be done with care. FNV_Primes were selected primarily for the 185 quality of resulting hash function, not for compiler optimization. 187 2.2 FNV offset_basis 189 The offset_basis values for the n-bit FNV-1a algorithms are computed 190 by applying the n-bit FNV-0 algorithm to the 32 octets representing 191 the following character string in [ASCII]: 193 chongo /\../\ 195 The \'s in the above string are not C-style escape characters. In C- 196 string notation, these 32 octets are: 198 "chongo /\\../\\" 200 2.3 FNV Endianism 202 For persistent storage or interoperability between different hardware 203 platforms, an FNV hash shall be represented in the little endian 204 format. That is, the FNV hash will be stored in an array hash[N] with 205 N bytes such that its integer value can be retrieved as follows: 207 unsigned char hash[N]; 208 for ( i = N-1, value = 0; i >= 0; --i ) 209 value = value << 8 + hash[i]; 211 Of course, when FNV hashes are used in a single process or a group of 212 processes sharing memory on processors with compatible endian-ness, 213 the natural endianness of those processors can be used regardless of 214 its type, little, big, or some other exotic form. 216 3. Other Hash Sizes and XOR Folding 218 Many hash uses require a hash that is not one of the FNV sizes for 219 which constants are provided in Section 4. If a larger hash size is 220 needed, please contact the authors of this document. 222 Most hash applications make use of a hash that is a fixed size binary 223 field. Assume that k bits of hash are desired and k is less than 1024 224 but not one of the sizes for which constants are provided in Section 225 4. The recommended technique is to take the smallest FNV hash of size 226 S, where S is larger than k, and calculate the desired hash using xor 227 folding as shown below. The final bit masking operation is logically 228 unnecessarily if the size of hash is exactly the number of desired 229 bits. 231 temp = FNV_S ( data-to-be-hashed ) 232 hash = ( temp xor temp>>k ) bitwise-and ( 2**k - 1 ) 234 Hash functions are a trade-off between speed and strength. For 235 example, a somewhat stronger hash may be obtained for exact FNV sizes 236 by calculating an FNV twice as long as the desired output ( S = 2*k ) 237 and performing such data folding using a k equal to the size of the 238 desired output. However, if a much stronger hash, for example one 239 suitable for cryptographic applications, is wanted, algorithms 240 designed for that purpose, such as those in [RFC6234], should be 241 used. 243 If it is desired to obtain a hash result that is a value between 0 244 and max, where max is a not a power of two, simply choose an FNV hash 245 size S such that 2**S > max. Then calculate the following: 247 FNV_S mod ( max+1 ) 249 The resulting remainder will be in the range desired but will suffer 250 from a bias against large values with the bias being larger if 2**S 251 is only a little bigger than max. If this bias is acceptable, no 252 further processing is needed. If this bias is unacceptable, it can be 253 avoided by retrying for certain high values of hash, as follows, 254 before applying the mod operation above: 256 X = ( int( ( 2**S - 1 ) / ( max+1 ) ) ) * ( max+1 ) 257 while ( hash >= X ) 258 hash = ( hash * FNV_Prime ) + offset_basis 260 4. FNV Constants 262 The FNV Primes are as follows: 264 32 bit FNV_Prime = 2**24 + 2**8 + 0x93 = 16,777,619 265 = 0x01000193 267 64 bit FNV_Prime = 2**40 + 2**8 + 0xB3 = 1,099,511,628,211 268 = 0x00000100 000001B3 270 128 bit FNV_Prime = 2**88 + 2**8 + 0x3B = 271 309,485,009,821,345,068,724,781,371 272 = 0x00000000 01000000 00000000 0000013B 274 256 bit FNV_Prime = 2**168 + 2**8 + 0x63 = 275 374,144,419,156,711,147,060,143,317,175,368,453,031,918,731,002,211 = 276 0x0000000000000000 0000010000000000 0000000000000000 0000000000000163 278 512 bit FNV_Prime = 2**344 + 2**8 + 0x57 = 35, 279 835,915,874,844,867,368,919,076,489,095,108,449,946,327,955,754,392, 280 558,399,825,615,420,669,938,882,575,126,094,039,892,345,713,852,759 = 281 0x0000000000000000 0000000000000000 0000000001000000 0000000000000000 282 0000000000000000 0000000000000000 0000000000000000 0000000000000157 284 1024 bit FNV_Prime = 2**680 + 2**8 + 0x8D = 5, 285 016,456,510,113,118,655,434,598,811,035,278,955,030,765,345,404,790, 286 744,303,017,523,831,112,055,108,147,451,509,157,692,220,295,382,716, 287 162,651,878,526,895,249,385,292,291,816,524,375,083,746,691,371,804, 288 094,271,873,160,484,737,966,720,260,389,217,684,476,157,468,082,573 = 289 0x0000000000000000 0000000000000000 0000000000000000 0000000000000000 290 0000000000000000 0000010000000000 0000000000000000 0000000000000000 291 0000000000000000 0000000000000000 0000000000000000 0000000000000000 292 0000000000000000 0000000000000000 0000000000000000 000000000000018D 294 The FNV offset_basis values are as follows: 296 32 bit offset_basis = 2,166,136,261 = 0x811C9DC5 298 64 bit offset_basis = 14695981039346656037 = 0xCBF29CE4 84222325 300 128 bit offset_basis = 144066263297769815596495629667062367629 = 301 0x6C62272E 07BB0142 62B82175 6295C58D 303 256 bit offset_basis = 100,029,257,958,052,580,907,070,968, 304 620,625,704,837,092,796,014,241,193,945,225,284,501,741,471,925,557 = 305 0xDD268DBCAAC55036 2D98C384C4E576CC C8B1536847B6BBB3 1023B4C8CAEE0535 306 512 bit offset_basis = 9, 307 659,303,129,496,669,498,009,435,400,716,310,466,090,418,745,672,637, 308 896,108,374,329,434,462,657,994,582,932,197,716,438,449,813,051,892, 309 206,539,805,784,495,328,239,340,083,876,191,928,701,583,869,517,785 = 310 0xB86DB0B1171F4416 DCA1E50F309990AC AC87D059C9000000 0000000000000D21 311 E948F68A34C192F6 2EA79BC942DBE7CE 182036415F56E34B AC982AAC4AFE9FD9 313 1024 bit offset_basis = 14,197,795,064,947,621,068,722,070,641,403, 314 218,320,880,622,795,441,933,960,878,474,914,617,582,723,252,296,732, 315 303,717,722,150,864,096,521,202,355,549,365,628,174,669,108,571,814, 316 760,471,015,076,148,029,755,969,804,077,320,157,692,458,563,003,215, 317 304,957,150,157,403,644,460,363,550,505,412,711,285,966,361,610,267, 318 868,082,893,823,963,790,439,336,411,086,884,584,107,735,010,676,915 = 319 0x0000000000000000 005F7A76758ECC4D 32E56D5A591028B7 4B29FC4223FDADA1 320 6C3BF34EDA3674DA 9A21D90000000000 0000000000000000 0000000000000000 321 0000000000000000 0000000000000000 0000000000000000 000000000004C6D7 322 EB6E73802734510A 555F256CC005AE55 6BDE8CC9C6A93B21 AFF4B16C71EE90B3 324 5. The Source Code 326 The following sub-sections provide reference C source code and a test 327 driver for FNV-1a. 329 Section 5.1 provides the direct FNV-1a function for each of the 330 lengths for which it is specified in this document. Note that for 331 applications of FNV-32 where 32-bit integers are supported and FNV-64 332 where 64-bit integers are supported, the code is sufficiently simple 333 that use of open coding or macros may be more appropriate to maximize 334 performance. 336 Section 5.2 provides a test driver. 338 5.1 FNV-1a Code 340 TBD 342 5.1.1 FNV32 Code 344 TBD 346 5.1.2 FNV64 C Code 348 TBD 350 5.1.3 FNV128 Code 352 TBD 354 5.1.4 FNV256 C Code 356 TBD 358 5.1.5 FNV512 C Code 360 TBD 362 5.1.6 FNV1024 C Code 364 TBD 366 5.2 FNV Test Code 368 TBD 370 6. Security Considerations 372 This document is intended to provide convenient open source access by 373 the Internet community to the FNV non-cryptographic hash. No 374 assertion of suitability for cryptographic applications is made for 375 the FNV hash algorithms. 377 6.1 Why is FNV Non-Cryptographic? 379 A full discussion of cryptographic hash requirements and strength is 380 beyond the scope of this document. However, here are three 381 characteristics of FNV that would generally be considered to make it 382 non-cryptographic: 384 1. Work Factor - To make brute force inversion hard, a cryptographic 385 hash should be computationally expensive, especially for a general 386 purpose processor. But FNV is designed to be very inexpensive on a 387 general-purpose processor. (See Appendix A.) 389 2. Sticky State - A cryptographic hash should not have a state in 390 which it can stick for a plausible input pattern. But, in the very 391 unlikely event that the FNV hash variable becomes zero and the 392 input is a sequence of zeros, the hash variable will remain at 393 zero until there is a non-zero input byte and the final hash value 394 will be unaffected by the length of that sequence of zero input 395 bytes. Of course, for the common case of fixed length input, this 396 would not be significant because the number of non-zero bytes 397 would vary inversely with the number of zero bytes and for some 398 types of input runs of zeros do not occur. Furthermore, the 399 inclusion of even a little unpredictable input may be sufficient 400 to stop an adversary from inducing a zero hash variable. 402 3. Diffusion - Every output bit of a cryptographic hash should be an 403 equally complex function of every input bit. But it is easy to see 404 that the least significant bit of a direct FNV hash is the XOR of 405 the least significant bits of every input byte and does not depend 406 on any other input bit. While more complex, the second through 407 seventh least significant bits of an FNV hash have a similar 408 weakness; only the top bit of the bottom byte of output, and 409 higher order bits, depend on all input bits. If these properties 410 are considered a problem, they can be easily fixed by XOR folding 411 (see Section 3). 413 Nevertheless, none of the above have proven to be a problem in actual 414 practice for the many applications of FNV. 416 7. IANA Considerations 418 This document requires no IANA Actions. RFC Editor Note: please 419 delete this section before publication. 421 Acknowledgements 423 The contributions of the following are gratefully acknowledged: 425 Frank Ellermann, Bob Moskowitz, and Stefan Santesson. 427 Normative References 429 [ASCII] - American National Standards Institute (formerly United 430 States of America Standards Institute), "USA Code for 431 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 432 has been replaced by newer versions with slight modifications, 433 but the 1968 version remains definitive for the Internet. 435 Informative References 437 [FNV] - FNV web site: 438 http://www.isthe.com/chongo/tech/comp/fnv/index.html 440 [IEEE] - http://www.ieee.org 442 [IPv6flow] - https://researchspace.auckland.ac.nz/bitstream/handle/ 443 2292/13240/flowhashRep.pdf 445 [RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 446 1 (SHA1)", RFC 3174, September 2001. 448 [RFC6194] - Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 449 Considerations for the SHA-0 and SHA-1 Message-Digest 450 Algorithms", RFC 6194, March 2011. 452 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 453 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 454 2011. 456 Appendix A: Work Comparison with SHA-1 458 This section provides a simplistic rough comparison of the level of 459 effort required per input byte to compute FNV-1a and SHA-1 [RFC3174]. 461 Ignoring transfer of control and conditional tests and equating all 462 logical and arithmetic operations, FNV requires 2 operations per 463 byte, an XOR and a multiply. 465 SHA-1 is a relatively weak cryptographic hash producing a 160-bit 466 hash. It that has been partially broken [RFC6194]. It is actually 467 designed to accept a bit vector input although almost all computer 468 uses apply it to an integer number of bytes. It processes blocks of 469 512 bits (64 bytes) and we estimate the effort involved in SHA-1 470 processing a full block. Ignoring SHA-1 initial set up, transfer of 471 control, and conditional tests, but counting all logical and 472 arithmetic operations, including counting indexing as an addition, 473 SHA-1 requires 1,744 operations per 64 bytes block or 27.25 474 operations per byte. So by this rough measure, it is a little over 13 475 times the effort of FNV for large amounts of data. However, FNV is 476 commonly used for small inputs. Using the above method, for inputs of 477 N bytes, where N is <= 55 so SHA-1 will take one block (SHA-1 478 includes padding and an 8-byte length at the end of the data in the 479 last block), the ratio of the effort for SHA-1 to the effort for FNV 480 will be 872/N. For example, with an 8 byte input, SHA-1 will take 109 481 times as much effort as FNV. 483 Stronger cryptographic functions than SHA-1 generally have an even 484 high work factor. 486 Appendix B: Previous IETF Reference to FNV 488 FNV-1a was referenced in draft-ietf-tls-cached-info-08.txt that has 489 since expired. It was later decided that it would be better to use a 490 cryptographic hash for that application. 492 Below is the Jave code for FNV64 from that TLS draft include by the 493 kind permission of the author: 495 496 /** 497 * Java code sample, implementing 64 bit FNV-1a 498 * By Stefan Santesson 499 */ 501 import java.math.BigInteger; 503 public class FNV { 505 static public BigInteger getFNV1aToByte(byte[] inp) { 507 BigInteger m = new BigInteger("2").pow(64); 508 BigInteger fnvPrime = new BigInteger("1099511628211"); 509 BigInteger fnvOffsetBasis = 510 new BigInteger("14695981039346656037"); 512 BigInteger digest = fnvOffsetBasis; 514 for (byte b : inp) { 515 digest = digest.xor(BigInteger.valueOf((int) b & 255)); 516 digest = digest.multiply(fnvPrime).mod(m); 517 } 518 return digest; 520 } 521 } 522 524 Appendix C: A Few Test Vectors 526 Below are a few test vectors in the form of ASCII strings and their 527 FNV32 and FNV64 hashes using the FNV-1a algorithm. 529 Strings without null (zero byte) termination: 531 String FNV32 FNV64 532 "" 0x811c9dc5 0xcbf29ce484222325 533 "a" 0xe40c292c 0xaf63dc4c8601ec8c 534 "foobar" 0xbf9cf968 0x85944171f73967e8 536 Strings including null (zero byte) termination: 538 String FNV32 FNV64 539 "" 0x050c5d1f 0xaf63bd4c8601b7df 540 "a" 0x2b24d044 0x089be207b544f1e4 541 "foobar" 0x0c1c9eb8 0x34531ca7168b8f38 543 Appendix Z: Change Summary 545 RFC Editor Note: Please delete this appendix on publication. 547 From -00 to -01 549 1. Add Security Considerations section on why FNV is non- 550 cryptographic. 552 2. Add Appendix A on a work factor comparison with SHA-1. 554 3. Add Appendix B concerning previous IETF draft referenced to FNV. 556 4. Minor editorial changes. 558 From -01 to -02 560 1. Correct FNV_Prime determination criteria and add note as to why s 561 < 5 and s > 10 are not considered. 563 2. Add acknowledgements list. 565 3. Add a couple of references. 567 4. Minor editorial changes. 569 From -02 to -03 571 1. Replace direct reference to US-ASCII standard with reference to 572 RFC 20. 574 2. Update dates and verion number. 576 3. Minor editing changes. 578 From -03 to -04 580 1. Change reference to RFC 20 back to a reference to the ANSI 1968 581 ASCII standard. 583 2. Minor addition to Section 6, point 3. 585 3. Update dates and version number. 587 4. Minor editing changes. 589 From -04 to -05 591 1. Add Twitter as a use example and IPv6 flow hash study reference. 593 2. Update dates and version number. 595 From -05 to -06 597 1. Add code subsections. 599 2. Update dates and version number. 601 From -06 to -07 to -08 603 1. Update Author info. 605 2. Minor edits. 607 Author's Address 609 Glenn Fowler 610 Google 612 Email: glenn.s.fowler@gmail.com 614 Landon Curt Noll 615 Cisco Systems 616 170 West Tasman Drive 617 San Jose, CA 95134 USA 619 Telephone: +1-408-424-1102 620 Email: fnv-ietf2-mail@asthe.com 621 URL: http://www.isthe.com/chongo/index.html 623 Kiem-Phong Vo 624 Google 626 Email: phongvo@gmail.com 628 Donald Eastlake 629 Huawei Technologies 630 155 Beaver Street 631 Milford, MA 01757 USA 633 Telephone: +1-508-333-2270 634 EMail: d3e3e3@gmail.com 636 Copyright, Disclaimer, and Additional IPR Provisions 638 Copyright (c) 2014 IETF Trust and the persons identified as the 639 document authors. All rights reserved. 641 This document is subject to BCP 78 and the IETF Trust's Legal 642 Provisions Relating to IETF Documents 643 (http://trustee.ietf.org/license-info) in effect on the date of 644 publication of this document. Please review these documents 645 carefully, as they describe your rights and restrictions with respect 646 to this document. Code Components extracted from this document must 647 include Simplified BSD License text as described in Section 4.e of 648 the Trust Legal Provisions and are provided without warranty as 649 described in the Simplified BSD License. This Internet-Draft is 650 submitted to IETF in full conformance with the provisions of BCP 78 651 and BCP 79.