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]