Versions: 00

INTERNET-DRAFT                                                   Bo Tian
Intended Status: Proposed Standard                                 Calix
Expires: October 2019

                                                          April 15, 2019

       Internet Protocol, Version 4 64-bit Address Extension
                    draft-tian-ipv4-64-bit-00

Abstract

   This document describes a 64-bit address mechanism that serves as an
   extension to IPv4, namely, IPv4_64.  As an add-on to IPv4, this
   extension is designed to solve the IPv4 address exhaustion issue in
   an innovative way, and slightly improve some IPv4 functions at the
   same time.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright Notice

   Copyright (c) 2019 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. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1  Motivation   . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2  IPv4_64 Header . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  IPv4_64 Header Format . . . . . . . . . . . . . . . . . . . .   5
   4.  IPv4_64 Extension Headers . . . . . . . . . . . . . . . . . .   6
   5.  IPv4-Compatible Considerations  . . . . . . . . . . . . . . .   6
     5.1  Res Field  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2  IPv4-Compatible IPv4_64 Address  . . . . . . . . . . . . .   7
     5.3  The Loose-in and Strict-out Rule . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7. Security Considerations  . . . . . . . . . . . . . . . . . . .   8
   8. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Although IPv4 address exhaustion has occurred, due to the risk, cost
   and complexity of applying new network technologies, it is clear that
   IPv4 is going to exist for a long time.  But current methods used to
   prolong the lifespan of IPv4 can only alleviated IPv4 address
   exhaustion issue to some extent.  Applying those technologies will
   inevitably face the continuously growing costs of running the IPv4
   network and the deficiency of the network connectivity.  This
   document describes a 64-bit address mechanism that serves as the
   extension to IPv4, namely, IPv4_64.  As an add-on to IPv4, this
   extension is designed to solve the IPv4 address depleted issue in an
   innovative way, and slightly improve some IPv4 functions at the same
   time.

   The choice of 64-bit is because that modern computer science has
   favoured 64-bit more than other number of bits as the upgrade from
   32-bit.  The 64-bit addresses will be more natural for modern
   computer and human to handle.

1.1  Motivation

   To mitigate IPv4 address exhaustion issue, a 64-bit address mechanism
   is introduced.  And a new header format is introduced to keep those
   64-bit address information.  When the originator or recipient is
   64-bit address or need to bear any other 64-bit address information
   in the header, the IPv4_64 header is used instead of the IPv4 one.

   The introduction of the IPv4_64 header also makes it possible to
   improve some functions of IPv4 while not breaking current IPv4
   network functions.  Most of those improvements are heavenly borrowed
   from IPv6, since IPv6 has done an excellent job in improving IPv4
   functions.

1.2  IPv4_64 Header

   In summary, the content of the IPv4_64 header falls primarily into
   the following categories:

      o  Expanded Addressing Capabilities

         IPv4_64 increases the IP address size from 32-bit to 64-bit, to
         support more levels of addressing hierarchy, a much greater
         number of addressable nodes, in a way that keeps compatible
         with IPv4.  No different configuration method of address is
         needed.  Any new configuration method must support IPv4
         networks as well.  Also, IPv4_64 64-bit addresses and IPv4
         32-bit addresses share the same address space.

      o  Header Format Simplification

         The IPv4_64 header format makes it possible to implements some
         simplification to IPv4 header.  Like IPv6, some IPv4 header
         fields have been made optional and removed from the header, to
         reduce the common-case processing cost of packet handling and
         to limit the bandwidth cost of the IPv4_64 header.

      o  Improved Support for Extensions and Options

         Like IPv6, changes in the way IP header options are encoded
         allows for more efficient forwarding, less stringent limits on
         the length of options, and greater flexibility for introducing
         new options in the future.

      o  Authentication and Privacy Capabilities

         Like IPv6, extensions to support authentication, data
         integrity, and (optional) data confidentiality are specified
         for IPv4_64 is also needed.

   This document specifies the basic format of IPv4_64 header and the
   initially defined extension and options for those IPv4 fields that
   have been removed from the header.  It also discusses the
   IPv4-compatible considerations.

2.  Terminology

   IPv4_64      IPv4 64-bit address extension.

   node         a device that implements IPv4 or IPv4_64.

   upper layer  see [RFC8200].

   packet       an IPv4 or IPv4_64 header plus payload.

3.  IPv4_64 Header Format

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  Res  |Type of Service|       Reserved                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Payload Length         |  Next Header  |  Time to Live |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  64-bit Source Address                        |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                64-bit Destination Address                     |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version              4-bit Internet Protocol number, be 4. See
                        [RFC791]

   Res                  4-bit reserved field, must be 0.

   Type of Service      8-bit type of service field, same as IPv4.

   Reserved             16-bit reserved field.  The value initialized by
                        the originator should be delivered to the
                        recipient without being changed.

   Payload Length       16-bit unsigned integer, same as IPv6.  Length
                        of the protocol payload, i.e., the rest of the
                        packet following this header, in octets,
                        including any extension headers.

   Next Header          8-bit selector, same as IPv6.  Identifies the
                        type of header immediately following this
                        header.  Uses the same values as the IPv4
                        Protocol field [RFC-1700 et seq.].

   Time to Live         8-bit unsigned integer, same as IPv4.

   Source Address       64-bit address of the originator of the packet.

   Destination Address  64-bit address of the intended recipient of the
                        packet (possibly not the ultimate recipient, if
                        a Routing header is present).

4.  IPv4_64 Extension Headers

   IPv6 has already devised the most sophisticated extension headers.
   Except some changes needed due to IPv4-compatible requirements and
   the 64-bit address space, IPv4_64 extension headers are identical
   to the IPv6 ones described in [RFC8200].

   IPv4_64 extension headers have the following modifications:

      * All the address fields should be changed to 64-bit.

      * References to the IPv6 header are replaced by references to the
        IPv4_64 header.

      * ICMP errors sent in the course of processing extension headers
        use ICMPv4 instead of ICMPv6.

      * Extensions to support authentication, data integrity, and
        (optional) data confidentiality are specified for IPv4_64 is
        also needed.

5.  IPv4-Compatible Considerations

   IPv4_64 headers are designed to work an add-on to IPv4.  No different
   configuration method needed, and any new configuration method for
   IPv4_64 must support IPv4 network as well.

5.1  Res Field

   The value of the IHL field of IPv4 will always be equal to or greater
   than 5 and the value 0, 1, 2, 3 and 4 are not used.  IPv4_64 headers
   use that field as Res field and set it to 0 to distinguish with IPv4
   ones.

5.2  IPv4-Compatible IPv4_64 Address

   The IPv4-Compatible IPv4_64 Address is used to address IPv4 nodes.
   The format of that address is as follows:

   |             32 bits            |           32 bits              |
   +--------------------------------+--------------------------------+
   |0000........................0000|         IPv4 address           |
   +--------------------------------+--------------------------------+

5.3  The Loose-in and Strict-out Rule

   To work as an add-on to IPv4 and not breaking current IPv4 functions,
   IPv4_64 takes the loose-in and strict-out rule.  When originating a
   packet, if possible, IPv4 headers should always be used.  While at
   the recipient, either the IPv4 header or the IPv4_64 header are
   equally accepted and processed.

6.  Packet Size Issues

   Even IPv4_64 headers slightly increase the header size by 4-byte, the
   MTU issues will arise. IPv4_64 follows the design of IPv6, requires
   that every link in the Internet have a MTU of 1280 octets or greater.
   Furthermore IPv4_64 also requires that every tunneling link in the
   Internet (for example, PPP links [RFC1661]) have a MTU of the sum of
   1280 octets + the tunneling overhead or greater.

7.  IANA Considerations

   IANA is requested to update the descriptions of IPv6 extension
   headers to reflect that they are not IPv6 specific (such as, can be
   applied to IPv4 and its extensions).

   In the Assigned Internet Protocol Numbers Registry, the modified
   protocols descriptions are:


    +----------+---------+------------+-----------+--------------------+
    |  Decimal | Keyword |  Protocol  | IPv6      |      Reference     |
    |          |         |            | Extension |                    |
    |          |         |            | header    |                    |
    +----------+---------+------------+-----------+--------------------+
    | 0        | HOPOPT  | Hop-by-Hop |           | [RFC8200]          |
    |          |         | Option     |           |                    |
    +----------+---------+------------+-----------+--------------------+
    | 43       | Route   | Routing    |           | [Steve_Deering]    |
    |          |         | Header     |           |                    |
    +----------+---------+------------+-----------+--------------------+
    | 44       | Frag    | Fragment   |           | [Steve_Deering]    |
    |          |         | Header     |           |                    |
    +----------+---------+------------+-----------+--------------------+
    | 59       | NoNxt   | No Next    |           | [RFC8200]          |
    |          |         | Header     |           |                    |
    +----------+---------+------------+-----------+--------------------+
    | 60       | Opts    | Destination|           | [RFC8200]          |
    |          |         | Options    |           |                    |
    +----------+---------+------------+-----------+--------------------+

8.  Security Considerations

   IPv4_64, from the viewpoint of the basic format and transmission of
   packets, has security properties that are similar to IPv4 and IPv6.

   Same to IPv6 and IPv4, these security issues include:

      o  Eavesdropping, where on-path elements can observe the whole
         packet (including both contents and metadata) of each IPv4_64
         datagram.
      o  Replay, where the attacker records a sequence of packets off of
         the wire and plays them back to the party that originally
         received them.
      o  Packet insertion, where the attacker forges a packet with some
         chosen set of properties and injects it into the network.
      o  Packet deletion, where the attacker removes a packet from the
         wire.
      o  Packet modification, where the attacker removes a packet from
         the wire, modifies it, and re-injects it into the network.
      o  Man-in-the-middle (MITM) attacks, where the attacker subverts
         the communication stream in order to pose as the sender to
         receiver and the receiver to the sender.
      o  Denial-of-service (DoS) attacks, where the attacker sends large
         amounts of legitimate traffic to a destination to overwhelm it.


   In modern network, the upper-layer protocols such as Transport Layer
   Security (TLS) or Secure Shell (SSH) can be used to protect the
   application-layer traffic running on top of IPv4_64.  IPv4_64 packets
   can also be protected from eavesdropping, replay, packet insertion,
   packet modification, and MITM attacks by updating the "Security
   Architecture for the Internet Protocol" [RFC4301] to support IPv4_64
   headers.

   There is not any mechanism to protect against DoS attacks.  Defending
   against these type of attacks is outside the scope of this
   specification.

   Similar to IPv6, IPv4_64 addresses of nodes are expected to be more
   visible on the Internet.  This creates some additional privacy issues
   such as making it easier to distinguish endpoints.

   Using the same extension header architecture with IPv6 also makes
   IPv4_64 face the similar security challenges with IPv6.  See
   [RFC8200] for more information.

8.  REFERENCES

8.1.  Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981, <http://www.rfc-editor.org/info/rfc791>.

   [RFC8200]  S. Deering and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 8200, July 2017,
              <https://tools.ietf.org/html/rfc8200>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005,
              <http://www.rfc-editor.org/info/rfc4301>.

   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
              STD 51, RFC 1661, July 1994,
              <http://www.rfc-editor.org/info/rfc1661>.

8.2.  Informative References

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998,
              <http://www.rfc-editor.org/info/rfc2474>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001,
              <http://www.rfc-editor.org/info/rfc3168>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              November 2011,
              <http://www.rfc-editor.org/info/rfc6437>.

Acknowledgments

   The authors gratefully acknowledge the many helpful suggestions of
   the members of the Internet community at large.

Authors' Addresses

   Bo Tian
   Calix

   Email: bo.tian@calix.com