idnits 2.17.1 draft-trammell-privsec-defeating-tcpip-meta-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '...EMPHATICALLY NOT RECOMMENDED for use o...' RFC 2119 keyword, line 307: '...s that the value MUST be ignored by mi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 29, 2016) is 2827 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6093' is defined on line 568, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-hardie-privsec-metadata-insertion-02 == Outdated reference: A later version (-03) exists of draft-thomson-postel-was-wrong-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Privacy and Security Program B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational July 29, 2016 5 Expires: January 30, 2017 7 Detecting and Defeating TCP/IP Hypercookie Attacks 8 draft-trammell-privsec-defeating-tcpip-meta-00 10 Abstract 12 The TCP/IP stack provides protocol features that can potentially be 13 abused by on-path attackers to inject metadata about a traffic flow 14 into that traffic flow in band. When this injected metadata is 15 provided by an entity with knowledge about the natural person 16 associated with a traffic flow, it becomes a grave threat to privacy, 17 which we term a hypercookie. 19 This document defines a threat model for hypercookie injection and 20 hypercookie coercion attacks, catalogs protocol features that may be 21 used to achieve them, and provides guidance for defeating these 22 attacks, with an analysis of protocol features that are disabled by 23 the proposed defeat mechanism. 25 The deployment of firewalls that detect and reject abuse of protocol 26 features can help, but the relative ease of injecting metadata for 27 attackers on path, and trivial combination of metadata injection 28 attacks, leads to a recommendation to add cryptographic integrity 29 protection to transport layer headers to defend against injection 30 attacks. 32 tl;dr: at least with respect to metadata injection in the current 33 Internet protocol stack, everything is ruined. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 30, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. General Mitigation Techniques and Related Work . . . . . . . 4 71 4. Metadata Injection Techniques . . . . . . . . . . . . . . . . 5 72 4.1. Abusing Internet Protocol features . . . . . . . . . . . 5 73 4.1.1. Identification using EUI-64 addressing . . . . . . . 5 74 4.1.2. Identification using DHCPv6 . . . . . . . . . . . . . 6 75 4.1.3. Identification using IPv6 network address translation 6 76 4.1.4. Identification using Flow ID . . . . . . . . . . . . 6 77 4.2. Abusing legacy Internet Protocol features . . . . . . . . 7 78 4.2.1. Fragment Identification Rewriting . . . . . . . . . . 7 79 4.3. Abusing Transmission Control Protocol Features . . . . . 7 80 4.3.1. Initial Sequence Number Rewriting . . . . . . . . . . 7 81 4.3.2. Urgent Pointer Identification . . . . . . . . . . . . 8 82 4.3.3. Piggybacked Experimental TCP Options . . . . . . . . 8 83 4.3.4. Bare ACK Segments with Experimental TCP Options . . . 9 84 4.3.5. Out of Window Segments . . . . . . . . . . . . . . . 9 85 4.3.6. Bad Checksum Segments . . . . . . . . . . . . . . . . 10 86 4.4. Combination of Techniques . . . . . . . . . . . . . . . . 10 87 5. Recommendations and Outlook . . . . . . . . . . . . . . . . . 10 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 93 9.2. Informative References . . . . . . . . . . . . . . . . . 11 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 96 1. Introduction 98 This document considers a specific threat model related to the 99 pervasive surveillance threat model defined in [RFC7624] and 100 correlation and identification of users as defined in sections 5.2.1 101 and 5.2.2, respectively, of [RFC6973]. The attacker has access to 102 the access network(s) connecting a user to the Internet, by 103 collaborating with, coopting, or otherwise exercising influence over 104 the user's access provider. It can see all inbound and outbound 105 traffic from the user via that network, and can modify inbound and 106 outbound packets to the user. The attacker would like to add 107 metadata to the user's traffic flows in order to expose that metadata 108 to networks the user communicates with, where it will be passively 109 observed, and it would like this metadata to appear in layers 3 or 4, 110 in order to be completely transparent to the application. For 111 purposes of this analysis, we presume this metadata is a user 112 identifier or partial user identifier. We propose a colloquial term 113 for this type of sub-application identification: "hypercookie". This 114 can be seen as a third-party implementation of the metadata insertion 115 pattern described in [I-D.hardie-privsec-metadata-insertion]. 117 The attacker is variably interested in avoiding detection of 118 hypercookie injection techniques, and is variably interested in 119 metadata reliability, but requires that the injected metadata not 120 interfere with normal protocol operation, even if the exposed 121 metadata is not used by any far endpoint. 123 The hypercookie injection attack is related to another, largely 124 equivalent attack, hypercookie coercion. In this attack, the 125 attacker requires the client endpoint to expose the hypercookie 126 itself, and uses in-band verification techniques to determine whether 127 the hypercookie was correctly applied, blocking traffic which does 128 not carry it. 130 This document is concerned only with identification through 131 hypercookie injection at the transport and network layers, as this is 132 possible even when the application layer is encrypted using TLS or 133 other encryption schemes that operate above the transport layer. 134 Application layer hypercookie injection is out of scope, as are 135 identification methods using traffic fingerprinting. It is also 136 concerned only with TCP as defined, not as implemented and deployed; 137 exploitation of other behaviors in implemented TCP stacks (e.g. as 138 outlined in [blind-tcp-attacks] may also be used for hypercookie 139 exposure, albeit with further risk of connection disruption. 141 Further, out-of-band identification methods, e.g. linking a flow's 142 five- or six-tuple with an identifier and using some other protocol 143 to export this linkage, is also not considered, as it is practically 144 impossible for users and far endpoints to detect and defeat. 146 The metadata injection techniques presented in this document are 147 EMPHATICALLY NOT RECOMMENDED for use on the Internet; this document 148 is intended to educate members of the Internet engineering community 149 about the potential for abuse in TCP as defined and deployed. 151 2. Terminology 153 As used in this document: 155 o "Stateless TCP firewall" refers to a middlebox [RFC3234] that 156 selectively drops single malformed TCP packets. A stateless TCP 157 firewall can defeat TCP metadata injection techniques which rely 158 on noncompliant formation of single TCP packets. 160 o "Stateful TCP firewall" refers to a middlebox that selectively 161 drops TCP packets not conforming to the protocol by modeling the 162 TCP state machine on both endpoints. A stateful TCP firewall can 163 defeat TCP metadata injection techniques which relies on 164 noncompliant formation of TCP packets and/or flows. 166 o "Split TCP proxy" refers to a middlebox which terminates a TCP 167 connection on one its Internet-facing side and opens a separate 168 TCP connection on the other side. Split TCP firewalls defeat most 169 of the TCP-specific metadata injection techniques in this 170 document. 172 3. General Mitigation Techniques and Related Work 174 The metadata injection techniques described in Section 4 share some 175 general properties: each places data into bits in the IP or TCP 176 header, injection of which is insignificant to the connectivity or 177 performance of the connection between the endpoints. To some extent, 178 this is a consequence of cleartext headers in IP and TCP and of 179 Postel's maxim [RFC1122]. Being liberal in what one accepts leaves 180 space between what the sender SHOULD/MUST send and what the receiver 181 will silently ignore, and these techniques exploit that space. 182 Changing transport stacks to fail fast and hard on the receiver side, 183 as recommended in [I-D.thomson-postel-was-wrong] would reduce this 184 space, but at the possible risk of connectivity instability during 185 the transition. 187 TCP HICCUPS [hiccups] proposes a method for cooperative discovery and 188 mitigation of middlebox manipulation. It uses many of the bits in 189 the header that could also be used for metadata injection, and as 190 such provides a concrete implementation of fail fast and hard, 191 mitigating TCP attacks as in Section 4.3. 193 The deployment of middleboxes to drop malformed packets or zero 194 fields that may be used in hypercookie attacks may help to reduce the 195 rate of success and therefore the incentive to perform hypercookie 196 injection. However, this must be balanced against the cost of 197 additional management complexity and the risk of further ossification 198 of the Internet protocol stack through even more widespread 199 deployment of transport-aware, stateful, packet-modifying 200 middleboxes. 202 The best defense comes from evolving the stack: Widespread deployment 203 transport protocol proposals that encrypt most or all of the 204 transport layer headers such as QUIC, or proposals to enable 205 generalized transport layer encapsulation and encryption such as 206 PLUS, would effectively mitigate the TCP attacks in Section 4.3. 208 4. Metadata Injection Techniques 210 This section describes metadata injection techniques against the TCP/ 211 IP stack, separated by whether they abuse the IPv4, IPv6, or TCP 212 protocols. 214 4.1. Abusing Internet Protocol features 216 Four attacks abuse the IPv6 header: three by injecting information 217 into IPv6 source addresses, one abusing the IPv6 flow label. 219 4.1.1. Identification using EUI-64 addressing 221 [RFC4291] section 2.5.1 required IPv6 interface identifiers for 222 Stateless Address Autoconfiguration (SLAAC) to be constructed using 223 modified EUI-64 format. This leaks the hardware address of a user's 224 terminal to the receiver and all devices along the path. Such 225 addresses are easily recognized, as well, given the presence of the 226 bytes 0xff and 0xfe at byte offsets 11 and 12 of the address. Though 227 [RFC7136] deprecates the significance of the IPv6 interface 228 identifier and [RFC4941] specifies a standard method for assigning 229 privacy addresses when using SLAAC, these addresses may still be in 230 use on the Internet and as such can be passively used as identifying 231 information along the path. 233 When present, this technique provides 47 bits of identifying 234 information on a per-node basis, present on each packet from the 235 node. Access network providers cannot force the use of EUI-64 236 addressing; however, see Section 4.1.3 for a related technique. 238 The mitigation is to disable EUI-64 based SLAAC at end hosts, 239 replacing it with [RFC4941] privacy addressing and/or DHCPv6 240 [RFC3315]. This is current recommended practice in any event. Both 241 of these mitigations come with limited additional overhead and/or 242 network management complexity. 244 4.1.2. Identification using DHCPv6 246 An attacker which runs or can influence the configuration of a DHCPv6 247 server from which a node gets its address can assign a source address 248 to that node, the interface identifier part of which can contain 249 identifying information. 251 When successful, this technique provides approximately 64 bits of 252 identifying information on a per-node basis, present on each packet 253 from the node. Access network providers can influence the use of 254 DHCPv6 addresses, depending on access network architecture. 256 The mitigation is to disable DHCPv6. In situations when a user 257 cannot practically do so without losing connectivity, this technique 258 can be identified in some cases through an analysis of the addresses 259 assigned to node(s) belonging to a user and determination of the 260 persistence of the linkage between an address or addresses and a 261 user. 263 4.1.3. Identification using IPv6 network address translation 265 An attacker which cannot influence the configuration of a DHCPv6 266 server can use network address translation to rewrite the interface 267 identifier part of an address to contain identifying information. 269 When successful, this technique provides approximately 64 bits of 270 identifying information on a per-node basis, present on each packet 271 from the node. 273 No user-initiated mitigation is possible with the present stack. 274 This technique can be detected by connecting to a remote host via 275 IPv6, which can then analyze the addresses assigned to node(s) 276 belonging to a user and determination of the persistence of the 277 linkage between an address or addresses and a user. 279 4.1.4. Identification using Flow ID 281 [RFC6437] defines the IPv6 flow label, a 20-bit field in every IPv6 282 packet. It is intended to replace source and destination port in 283 equal-cost multipath routing (ECMP) and other load distribution 284 schemes. However, the flow label can be freely rewritten by 285 middleboxes on path. 287 This technique provides up to 20 bits of identifying information per 288 packet, with the caveat that applying different flow labels to 289 different packets within a flow may impair transport layer 290 performance due to reordering. 292 No user-initiated mitigation is possible with the present stack. 293 Header modification detection as in [hiccups], and/or the deployment 294 of middleboxes that monitor and/or zero the flow label may provide 295 detection and mitigation. 297 4.2. Abusing legacy Internet Protocol features 299 One attack injects information into the IPv4 fragment ID header. 301 4.2.1. Fragment Identification Rewriting 303 [RFC6864] defines the Identification field in the IPv4 header, which 304 is used for fragmentation and fragment reassembly. While the field 305 is only defined when a packet is fragmented, middleboxes can freely 306 fill identifying information into this field. [RFC6864] section 4.1 307 states that the value MUST be ignored by middleboxes, so it will tend 308 to be preserved along the path assuming compliant devices. 310 This technique provides up to 16 bits of identifying information per 311 packet, with a caveat that it may be difficult to implement on 312 networks with large amounts of fragmented IPv4 traffic. 314 There is no user-initiated mitigation possible with deployed IPv4 315 stacks. Header modification detection as in [hiccups] may provide 316 detection and mitigation 318 4.3. Abusing Transmission Control Protocol Features 320 A multitude of techniques exist to abuse TCP. These can be roughly 321 classified into per-packet injection, where metadata can be added to 322 header bits in each packet; and per-flow injection, where packets not 323 part of the normal flow are generated and ignored by the receiver. 324 Per-flow injection techniques generally provide much more space for 325 metadata injection, and are sufficient for user identification for 326 access control and user tracking on a per-flow basis. 328 4.3.1. Initial Sequence Number Rewriting 330 A middlebox can rewrite the initial sequence number (ISN) of flows it 331 sees the SYN packet for, in order to place identifying information 332 therein. 334 This technique provides up to 32 bits of identifying information per 335 flow, with the caveat that it requires a stateful middlebox to 336 translate all sequence and acknowledgment numbers on subsequent 337 packets on the flow. It also does not work if there are other 338 proxies which rewrite the ISN (e.g. for security, to mitigate poor 339 randomness in 1990s era TCP stace ISN selection algorithms) on the 340 path between the middlebox and the Internet. The identification 341 provided by this technique also does not traverse split-TCP proxies. 343 Header modification detection as in [hiccups] or the aggressive 344 deployment of split-TCP proxies can mitigate this attack. We note 345 that the aggressive deployment of split-TCP proxies in the Internet 346 is an undesirable solution, as it implies an acceleration and 347 deepening of middlebox-related transport protocol ossification. 349 4.3.2. Urgent Pointer Identification 351 A middlebox can rewrite the urgent pointer of TCP packets without the 352 URG flag set, in order to place identifying information therein. The 353 urgent pointer is only intepreted when the URG flag is set, according 354 to section 3.1 of [RFC0791]; compliant implementations will therefore 355 ignore the urgent pointer when used in this manner. 357 This technique provides up to 16 bits of identifying information per 358 packet. 360 Information exposed using this technique may not traverse TCP 361 firewalls or split TCP proxies. The aggressive deployment of 362 stateless TCP firewalls that zero the urgent pointer on all packets 363 with the URG flag not set can mitigate this attack, at the cost of 364 increased operational complexity and further middlebox-related 365 transport protocol ossification. 367 4.3.3. Piggybacked Experimental TCP Options 369 A middlebox can piggyback an experimental TCP option onto a TCP 370 packet with enough headroom, and place identifying information in 371 that option. This option could even be given a IANA identifier using 372 the ExId mechanism [RFC6994], registered with IANA on a First-Come, 373 First-Served [RFC5226] basis, with an innocuous name, in order to 374 deflect suspicion about its use. 376 Assuming a 4-byte ExId, sufficient headroom between the segment size 377 and the path MTU, and no other TCP options on a packet, this 378 technique can provide up to 288 bits of identifying information per 379 packet given limitations on TCP options size. We note that this is 380 an upper bound, and that the transparency of Internet paths to 381 unknown and experimental TCP options is not perfect, which reduce the 382 applicability of this technique somewhat. 384 Information exposed using this technique may not traverse TCP 385 firewalls or split TCP proxies. The aggressive deployment of 386 stateless TCP firewalls that strip experimental options not in use on 387 a given network can mitigate this attack. We note that some deployed 388 TCP Fast Open [RFC7413] implementations use an experimental option, 389 and would be affected by this mitigation. This mitigation also 390 incurs the cost of increased operational complexity and further 391 middlebox-related transport ossification. 393 4.3.4. Bare ACK Segments with Experimental TCP Options 395 As with the attack in Section 4.3.3, above, a middlebox could simply 396 generate a suitable bare ACK packet within a flow, but not initiated 397 by the sender, and place information in an experimental TCP option. 398 The bare ACK would be processed by the receiver and the option 399 ignored. 401 This technique can provide up to 288 bits of identifying information 402 per flow given limitations on TCP options size. Note that multiple 403 bare ACKs can be used to extend the amount of information injected 404 per flow. 406 Mitigations and caveats thereon are as in Section 4.3.3, above. 408 4.3.5. Out of Window Segments 410 A middlebox that keeps state for each TCP connection traversing it 411 can place out-of-window segments sharing a given 5-tuple but not 412 initiated by the sender on the wire. These segments should traverse 413 any device not looking at TCP state, and be ignored by the receiver. 415 This technique can provide over 11000 bits of identifying information 416 per flow given a 1500 byte MTU. Note that multiple out of window 417 segments can be used to extend the amount of information injected per 418 flow. 420 Information exposed using this technique may not traverse stateful 421 TCP firewalls or split TCP proxies. Existing stateful TCP firewalls 422 already provide out-of-window segment dropping, due to their 423 usefulness in TCP session hijacking attacks (see [blind-tcp-attacks] 424 for more). The aggressive deployment of stateful TCP firewalls that 425 drop and warn on out- of-window segments can mitigate this attack. 426 This mitigation incurs the cost of increased operational complexity 427 and further middlebox-related transport ossification. 429 4.3.6. Bad Checksum Segments 431 Similar to Section 4.3.5, a middlebox can place segments with bad 432 checksums sharing a given 5-tuple on the wire. These segments should 433 traverse any device not looking at TCP state, and be ignored by the 434 receiver. 436 Per-flow information and mitigations along with caveats are as in 437 Section 4.3.5. 439 4.4. Combination of Techniques 441 Note that multiple techniques above may be combined on any given 442 packet or over the sequence of packets in any given flow in order to 443 increase the number of bits available and/or increase the resilience 444 of the injected information to mitigation. 446 5. Recommendations and Outlook 448 An analysis of the hypercookie attacks listed in this document, and 449 the ability to combine them freely to improve hypercookie resilience 450 and capacity, leads to a relatively bleak outlook. Mitigating the 451 threat at scale with the stack as presently deployed requires 452 impractically aggressive, altruistic deployment of TCP-modifying 453 firewalls. 455 We therefore conclude that the most practical mitigation of this 456 threat is the development and deployment of transport protocols that 457 provide cryptographic integrity protection and/or confidentiality for 458 their headers, in order to prevent hypercookie injection at the 459 transport layer. 461 Note that these mitigations can only detect, but not prevent, 462 hypercookie coercion attacks: if an attacker can successfully block a 463 client's access to the Internet to enforce hypercookie coercion, 464 removal of metadata will not restore that access, as the attack is 465 carried out through nontechnical relationships between the attacker 466 and the target. We can only hope that raising awareness and bringing 467 transparency to the potential for hypercookie coercion attacks makes 468 them less likely to be successful. 470 6. IANA Considerations 472 This document has no actions for IANA [EDITOR'S NOTE: please remove 473 this section at publication.] 475 7. Security Considerations 477 This document outlines vulnerabilities in the TCP/IP protocol stack 478 as deployed to a type of attack described in Section 1. Exploitation 479 of these vulnerabilities can be used to expose identifying 480 information about users of a network to third parties; the document 481 discusses general and specific techniques to mitigate the impact of 482 these exploits. 484 8. Acknowledgments 486 This work is supported by the European Commission under Horizon 2020 487 grant agreement no. 688421 Measurement and Architecture for a 488 Middleboxed Internet (MAMI), and by the Swiss State Secretariat for 489 Education, Research, and Innovation under contract no. 15.0268. This 490 support does not imply endorsement. 492 Thanks to Ted Hardie, Joe Hildebrand, Mirja Kuehlewind, and the 493 participants at the PLUS BoF at IETF 96 in Berlin for the 494 conversations leading to and informing the publication of this 495 document. 497 9. References 499 9.1. Normative References 501 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 502 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 503 . 505 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 506 Morris, J., Hansen, M., and R. Smith, "Privacy 507 Considerations for Internet Protocols", RFC 6973, 508 DOI 10.17487/RFC6973, July 2013, 509 . 511 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 512 Trammell, B., Huitema, C., and D. Borkmann, 513 "Confidentiality in the Face of Pervasive Surveillance: A 514 Threat Model and Problem Statement", RFC 7624, 515 DOI 10.17487/RFC7624, August 2015, 516 . 518 9.2. Informative References 520 [blind-tcp-attacks] 521 Luckie, M., Beverly, R., Wu, T., Allman, M., and K. 522 Claffy, "Resilience of Deployed TCP to Blind Attacks", 523 2015, . 525 [hiccups] Craven, R., Beverly, R., and M. Allman, "A Middlebox- 526 Cooperative TCP for a non End-to-End Internet", 2014, 527 . 530 [I-D.hardie-privsec-metadata-insertion] 531 Hardie, T., "Design considerations for Metadata 532 Insertion", draft-hardie-privsec-metadata-insertion-02 533 (work in progress), March 2016. 535 [I-D.thomson-postel-was-wrong] 536 Thomson, M., "The Harmful Consequences of Postel's Maxim", 537 draft-thomson-postel-was-wrong-00 (work in progress), 538 March 2015. 540 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 541 DOI 10.17487/RFC0791, September 1981, 542 . 544 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 545 Communication Layers", STD 3, RFC 1122, 546 DOI 10.17487/RFC1122, October 1989, 547 . 549 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 550 C., and M. Carney, "Dynamic Host Configuration Protocol 551 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 552 2003, . 554 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 555 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 556 2006, . 558 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 559 Extensions for Stateless Address Autoconfiguration in 560 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 561 . 563 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 564 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 565 DOI 10.17487/RFC5226, May 2008, 566 . 568 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 569 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 570 January 2011, . 572 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 573 "IPv6 Flow Label Specification", RFC 6437, 574 DOI 10.17487/RFC6437, November 2011, 575 . 577 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 578 RFC 6864, DOI 10.17487/RFC6864, February 2013, 579 . 581 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 582 RFC 6994, DOI 10.17487/RFC6994, August 2013, 583 . 585 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 586 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 587 February 2014, . 589 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 590 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 591 . 593 Author's Address 595 Brian Trammell 596 ETH Zurich 598 Email: ietf@trammell.ch