Internet DRAFT - draft-gams-ipv4-extension
draft-gams-ipv4-extension
Internet Engineering Task Force MG.
Internet-Draft September 12, 2010
Intended status: Experimental
Expires: March 16, 2011
IPv4 Multi-Dimensional Extension
draft-gams-ipv4-extension-00
Abstract
IPv4 addresses are running out. I aim to create an extension to IPv4
that will allow organizations to migrate to a larger address space
without the need to replace all existing IPv4 devices and software.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 16, 2011.
Copyright Notice
Copyright (c) 2010 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.
Expires March 16, 2011 [Page 1]
Internet-Draft IPv4 Extension September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Address Prefixes . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4
Expires March 16, 2011 [Page 2]
Internet-Draft IPv4 Extension September 2010
1. Introduction
IPv4 addresses are running out and IPv6 does not provide complete
compatibility with IPv4. Providing prefixes to the 32-bit IPv4
address space will provider larger amounts of addresses while making
it easier to migrate from traditional IPv4 networks.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
2. Address Prefixes
In order to provide larger address space, multi-homing capabilities,
and similar properties of IPv6, including mobility addressing, I
proposed the creation of a 96-bit locater ID that would prepend the
32-bit IPv4 address. In addition there would be a 64-bit multi-
homing ID available for organizations that require multi-homing.
The 96-bit locater ID will have the high order 64-bits assigned to
ISPs and possibly large organizations by IANA. This will leave 32-
bits for subdivision by the ISPs, and for special addressing such as
multicast, and mobility addressing unique to the provider level.
Multicast and mobility addressing could also have a unique 64-bit ID
assigned or possible use of the multi-homing ID as well.
The 64-bit multi-homing ID would have the high order 48-bits assigned
to organizations requiring multi-homing. This would leave 16-bits
for path determination under control of the organization assigned
multi-homing ID. Multi-homing IDs would then be registered with
providers as needed.
During transition and before 100% adoption, 32-bit IPv4 addresses
would still need to be unique and NAT/PAT would be necessary. After
full adoption 32-bit IPv4 address suffixes could repeat within ISPs
using the 96-bit locater ID to provide unique addressing. Locating
multi-homed addresses would require only the 64-bit multi-home ID and
the 32-bit IPv4 compatible address as the Internet routers would have
the mappings of multi-home ID to provider ID.
Preferred multi-home pathing would use normal BGP path determination
for any given 32-bit compatible IPv4 network if the lower 16-bit
portion of the multi-home ID is all zeros. However, the organization
could advertise different 16-bit values to the various providers
allowing a certain path to be preferred based on the value
Expires March 16, 2011 [Page 3]
Internet-Draft IPv4 Extension September 2010
advertised.
Address Layout
+----------------------------------------------------------+
| <64-bit MH ID> <96-bit Locater ID> <32-bit IPv4 Address> |
|__________________________________________________________|
Figure 1
3. IANA Considerations
IANA would be required to maintain the 64-bit portion of the 96-bit
locater ID, as well as, the 48-bit portion of the 64-bit multi-homing
ID.
4. Security Considerations
Properly encrypted authentication between routing peers MUST be
considered. Not doing so could lead to Peer impersonation or denial
of service attacks.
Author's Address
Matthew Gams
658 W 4th Ave
Oshkosh, WI 54902
US
Phone: +1 920 216 6754
Email: muskrat7@gmail.com
Expires March 16, 2011 [Page 4]
