Internet DRAFT - draft-tian-ipv4-64-bit
draft-tian-ipv4-64-bit
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
