Additional Transition Functionality for IPv6
RFC 8136

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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].