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
Carpenter & Hinden Informational [Page 1]
RFC 8136 Additional IPv6 Transition Functionality 1 April 2017
Table of Contents
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 PacketsThe 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].
Carpenter & Hinden Informational [Page 3]
RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 4. Advanced SolutionIn 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).
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
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 than conventional privacy techniques like IPsec and Transport Layer Security (TLS) as no encryption or key management is required to achieve the desired privacy.
Carpenter & Hinden Informational [Page 4]
RFC 8136 Additional IPv6 Transition Functionality 1 April 2017 5. Security ConsiderationsThe 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.
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 -
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,
7.2. Informative References
[IABv6] IAB, "IAB Statement on IPv6", November 2016,
Carpenter & Hinden Informational [Page 6]
RFC 8136 Additional IPv6 Transition Functionality 1 April 2017
Authors' Addresses