INFORMATIONAL

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 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 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 RFC2119]. 2 . Required Function of All IPv4 Nodes 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 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 RFC3514]. The other bits are reserved and MUST be zero or one. 4.1 . Privacy Extension 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