From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8136.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc8136.txt (limited to 'doc/rfc/rfc8136.txt') diff --git a/doc/rfc/rfc8136.txt b/doc/rfc/rfc8136.txt new file mode 100644 index 0000000..c04a04b --- /dev/null +++ b/doc/rfc/rfc8136.txt @@ -0,0 +1,395 @@ + + + + + + +Independent Submission B. Carpenter +Request for Comments: 8136 Univ. of Auckland +Category: Informational R. Hinden +ISSN: 2070-1721 Check Point Software + 1 April 2017 + + + Additional Transition Functionality for IPv6 + +Abstract + + This document proposes an additional mechanism intended to both + facilitate transition from IPv4 to IPv6 and improve the latter's + security and privacy. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8136. + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + +Carpenter & Hinden Informational [Page 1] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Required Function of All IPv4 Nodes . . . . . . . . . . . . . 2 + 3. Security Flag for IPv6 Packets . . . . . . . . . . . . . . . 3 + 4. Advanced Solution . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Privacy Extension . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 + 7.2. Informative References . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + In a recent statement [IABv6], the Internet Architecture Board deemed + that the Internet Engineering Task Force is expected to "stop + requiring IPv4 compatibility in new or extended protocols" and that + future work will "optimize for and depend on IPv6". In the interest + of promoting these goals, this memo makes an important change to IPv4 + node requirements [RFC1122] and adds a missing security feature to + IPv6 [RFC2460]. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are not to be interpreted as described in + [RFC2119]. + +2. Required Function of All IPv4 Nodes + + To ensure that all routers, firewalls, load balancers, and other + forms of middleboxes can readily identify IPv4 packets and deal with + them appropriately (selective dropping, switching to the slow path + through a router, sending them to the longest path first, etc.), all + IPv4 nodes MUST set the security flag defined by [RFC3514] to 1. + This should be sufficient to ensure that implementers of dual stack + applications prefer IPv6 when given the choice, and that the Happy + Eyeballs algorithm [RFC6555] will usually favour the IPv6 path. + + + + + + + + + +Carpenter & Hinden Informational [Page 2] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + +3. Security Flag for IPv6 Packets + + The above requirement will somewhat nullify the practical effect of + the IPv4 security flag for benign traffic, but this disadvantage can + readily be overcome by adding an equivalent flag for IPv6; in fact, + this is highly desirable to maintain feature equivalence between IPv4 + and IPv6. Fortunately, this can easily be achieved since IPv6 + supplies so many bits. The solution defined here is that the + Security Flag bit for an IPv6 packet is simply the parity of the + source address of the packet. In other words, if the source address + contains an odd number of 1s, the flag is True; otherwise, it's + False. All other considerations for the flag are exactly as + described in [RFC3514]. + + For an interface whose IPv6 address is set by Stateless Address + Autoconfiguration [RFC4862], it is the host itself that determines + the state of its security flag, by choosing an appropriate Interface + Identifier value. Fortunately this is now possible and compatible + with [RFC7136], [RFC7217], [RFC7421], and [RFC7721]. + + For an interface whose IPv6 address is set by DHCPv6 [RFC3315] or + manually, the network administrator is free to choose an Interface + Identifier that provides the desired security flag that is also + compatible with [RFC7721]. + + An exception case is a link with a 127-bit prefix [RFC6164]. Since + there is only one bit available as an Interface Identifier, one end + or the other will inevitably have its security flag set, and the + other won't. In this case, the node at one end will simply interpret + the other end's security flag to mean the opposite of what it says, + and vice versa. + + Since RFC 6164 is designed for links between routers, in the case + where different ISPs are at each end of the link, it is normal + operational practice for one ISP to consider the other ISP to be + evil. + + + + + + + + + + + + + + + +Carpenter & Hinden Informational [Page 3] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + +4. Advanced Solution + + In the event that the previous solution proves too simple to deploy + in practice, a more advanced solution is also defined. It uses a new + IPv6 hop-by-hop User Security Flag Option (UFO). + + The UFO is a hop-by-hop option that can be included in any IPv6 + packet. Multiple UFOs MUST NOT be present in the packet. The UFO + has no alignment requirement. Its format is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Type | Option Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | UserSecFlag | + +-+-+-+-+-+-+-+-+ + + User Security Flag Option Layout + + Option Type + + 8-bit identifier of the type of option. The option identifier + for the User Security Flag Option (0x7g) has not been allocated + by the IANA. + + Option Length + + 8-bit unsigned integer. The length of the option (excluding the + Option Type and Option Length fields). The value MUST be 1. + + UserSecFlag + + 8-bit unsigned integer. Bit 0 has the functionality defined in + [RFC3514]. The other bits are reserved and MUST be zero or one. + +4.1. Privacy Extension + + The mechanism can be extended to add a privacy flag. With the + mechanism of Section 3, the privacy flag could be encoded by using + quaternary parity (CRC-2) to obtain an extra bit. However, this + would waste considerable amounts of address space and SHOULD NOT be + done. With the UFO mechanism, bit 1 of UserSecFlag is defined as the + privacy flag. If set, it means that the packet contains private + information and MUST NOT be inspected en route. All firewalls, + monitoring devices, and government agencies MUST respect this rule. + This option is expected to be much more computationally efficient + + + + +Carpenter & Hinden Informational [Page 4] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + + than conventional privacy techniques like IPsec and Transport Layer + Security (TLS) as no encryption or key management is required to + achieve the desired privacy. + +5. Security Considerations + + The security considerations of [RFC3514] now apply to IPv6. However, + with the security flag being set for all IPv4 packets, there is a + risk that all IPv4 traffic will now be treated as a very distributed + denial-of-service attack. + + Given the recent experience with very large scale DDoS attacks from + Internet of Things (IoT) devices like IP Cameras, phishing attacks, + malware, etc., that occur on the IPv4 Internet, it is a safe + assumption that all IPv4 packets are evil. + + Since the mechanism described in Section 3 is compatible with + [RFC7721], address privacy is not impacted. Also, with that + mechanism, exactly half the IPv6 address space will indicate that the + security flag is set, so we can assert that the IPv6 Internet is only + half evil. + +6. IANA Considerations + + This document does not require any IANA actions. + +7. References + +7.1. Normative References + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + + + + + + + + +Carpenter & Hinden Informational [Page 5] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, . + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . + + [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, + L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- + Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, + . + + [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with + Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April + 2012, . + + [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 + Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, + February 2014, . + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + . + +7.2. Informative References + + [IABv6] IAB, "IAB Statement on IPv6", November 2016, + . + + [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", + RFC 3514, DOI 10.17487/RFC3514, April 2003, + . + + [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., + Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit + Boundary in IPv6 Addressing", RFC 7421, + DOI 10.17487/RFC7421, January 2015, + . + + [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy + Considerations for IPv6 Address Generation Mechanisms", + RFC 7721, DOI 10.17487/RFC7721, March 2016, + . + + + +Carpenter & Hinden Informational [Page 6] + +RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 + + +Authors' Addresses + + Brian Carpenter + Department of Computer Science + University of Auckland + PB 92019 + Auckland 1142 + New Zealand + + Email: brian.e.carpenter@gmail.com + + + Robert M. Hinden + Check Point Software + 959 Skyway Road + San Carlos CA 94070 + United States of America + + Email: bob.hinden@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Carpenter & Hinden Informational [Page 7] + -- cgit v1.2.3