Internet-Draft Alessandro Spinella Intended status: Proposed Standard Communication Valley Expires: July 24, 2009 January 20, 2009 Never Ending Network Addresses: IPv4 Multiplexing through IPv6 draft-nena-ip4-ip6-mux-01.txt 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 24, 2009. Copyright Notice Copyright (c) 2009 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. Abstract While the wide use of IPv4 "private" addresses [RFC1918] lead to a great flexibilty degree of uninterconnected networks and use of IPv6 offer a huge address space; no "nice" mechanism exist to hide overlap of existing IPv4 "private" networks if and when the sum of used address spaces is greater than the IPv4 "private" address space. This document specifies how to walk around the matter without any coordination, renumbering or IPv6 adoption by overlapping networks owners. Spinella Expires July 24, 2009 [Page 1] Internet-Draft IPv4 Multiplexing through IPv6 July 2009 Table of Contents 1. Introduction ................................................ 2 2. Specifications .............................................. 3 2.1. Address specifications ................................... 3 2.2. Communication skema ...................................... 4 2.3. CNID structure ........................................... 5 2.4. Routing considerations ................................... 5 3. Security considerations ..................................... 6 4. IANA considerations ......................................... 6 5. References ................................................... 6 5.1. Normative References ..................................... 6 5.2. Informative References ................................... 6 6. Acknowledgements ............................................ 6 7. Author's address ............................................ 6 1. Introduction 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 RFC 2119. [RFC2119] Users of IPv4 "private" addresses often delegate management of some of their hosts to External Company(s) (EC) through "ad hoc" communication links and can't migrate them to IPv6 in short terms; but management hosts in such EC need to communicate with all of managed networks/hosts, even if their addresses are not unique for it's point of view. In simple cases Network Address Translation (NAT) is sufficient to hide such overlaps, but there is a limit: when the sum of used address spaces is greater than the whole IPv4 "private" address space the NAT mechanism need more addresses than the available ones. Port Address Translation (PAT) is another way to do job: it works, but will soon become a nightmare to mantain the associations in dinamically growing networks. As long as many globally-overlapping addreses can be hidden by a small pool of globally-unique in a nice fashion when the pool of globally-overlapping host is "client" of globally-unique "server" host(s), it is an always-growing-matter to add/remove networks into the global map when the overlapping IPv4 "private" networks are both sources and targets of management-hosts traffic flows because it requires interactive cooperation of globally-overlapping network owners with the EC. Another simple, horribly unscalable solution is to add devices owned by the EC into existing networks: they have just as much topology knowledge as needed, but in time of troubles they can't access or be accessed by the "full resources" of the EC. Spinella Expires July 24, 2009 [Page 2] Internet-Draft IPv4 Multiplexing through IPv6 July 2009 This document provides specifications for a mechanism that saves both indipendence of each customer in choosing their own host addressing skema than global-host-reachability for the EC that manage them. 2. Specifications 2.1. Address specifications Given the following definitions [RFC4291] of : IPv4-Compatible IPv6 Address | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ and IPv4-Mapped IPv6 Address | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ The 16 bit block can be used to differentiate networks in which 32 bit IPv4 addresses are identical, leading to definition of : IPv4-Multiplexed IPv6 Address | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|CNID| IPv4 address | +--------------------------------------+----+---------------------+ where Customer Network ID (CNID) ranges between 0x1 and 0xFFFE thus allowing coexistence of 65534 address spaces as wide as the IPv4 InterNet. Spinella Expires July 24, 2009 [Page 3] Internet-Draft IPv4 Multiplexing through IPv6 July 2009 2.2. Communication skema Assigning souch a CNID to every customer overlapping network removes ambiguity of IPv4 addresses; an IPv6 host (H6) placed in EC network can now send/receive a packet to/from any of IPv4 hosts (H4) in any of multiplexed network, given an IPv6-to-IPv6 NAT capable gateway (GW66) for each used CNID. While dual-stack routers (GW64) are able to traslate addresses between IPv4 and IPv6, the problem reduces to change CNID before ingress and after egress of them as in: (a) (b) (c) H6 <-----------> GW66 <------------> GW64 <----------> H4 -------------- IPv6 --- (No CNID) ----|------- IPv4 ----- where IPv6 is used in segments (a), (b) and IPv4 in segment (c). Segment (a) has 0 < CNID < 65535; segment (b) has 0x0 or 0xFFFF. Because "IPv4-Compatible IPv6 Address" are deprecated [RFC4291] them MAY be used, but "IPv4-Mapped IPv6 Address" are RECOMMENDED. There is a drawback : no IPv6-to-IPv6 NAT-capable gateways exists, so we need at least a simple one that force all CNID bits to zeroes (for IPv4-Compatible IPv6 Address) or ones (for IPv4-Mapped IPv6 Address) before a packet leaves the interface connected to GW64 and force them to CNID before release of packet to H6 as in : | sender | source address | destination address | receiver | +--------+---------------------+-----------------------+----------+ | H6 | IPv6 global-unicast | IPv4-Multiplexed IPv6 | GW66 | +--------+---------------------+-----------------------+----------+ | GW66 | IPv6 global-unicast | IPv4-Mapped IPv6 | GW64 | +--------+---------------------+-----------------------+----------+ | GW64 | IPv4 | IPv4 | H4 | +--------+---------------------+-----------------------+----------+ and | sender | source address | destination address | receiver | +--------+-----------------------+---------------------+----------+ | H4 | IPv4 | IPv4 | GW64 | +--------+-----------------------+---------------------+----------+ | GW64 | IPv4-Mapped IPv6 | IPv6 global-unicast | GW66 | +--------+-----------------------+---------------------+----------+ | GW66 | IPv4-Multiplexed IPv6 | IPv6 global-unicast | H6 | +--------+-----------------------+---------------------+----------+ Spinella Expires July 24, 2009 [Page 4] Internet-Draft IPv4 Multiplexing through IPv6 July 2009 2.3. CNID structure The 16 bit CNID can be used as a flat space or structured one, at EC network-manager will; the following skema is both simple and flexible and SHOULD be considered as default : ::0000:IPv4-address == IPv4-Compatible IPv6 Addres ::0001:IPv4-address ==> CNID 0x1 identifies "customer-1" ...... ::7FFF:IPv4-address ==> CNID 0x7FFF identifies "customer-32767" ::8000:IPv4-address ==> first "special pourposes" CNID ..... ::FFFE:IPv4-address ==> last "special pourposes" CNID ::FFFF:IPv4-address ==> IPv4-Mapped IPv6 Address In a flat CNID space "special pourposes" are simply casted to be equal to "normal" ones; subspacing of "special pourposes" can be easily done as needed using more bits than the most significant one. 2.4. Routing considerations The H6(s) MUST know a different gateway for each customer address space to avoid complexity in IPv6-to-IPv6 NAT; in such a way GW66 need to be aware of just a default route on it's "internal" interface (the one belonging to management network) and a specific route for ::0/96 on "external", the one connected to customer GW64. But complexity exist and can't be circumvented in a scalable solution [RFC1925]. Whenever the routing table of H6s become complex MAY be convenient the introduction of a router between H6s and GW66s to isolate complexity in one device instead to spread it in all H6s. It is almost equal to have a "complex" IPv6-to-IPv6 NAT device, but it delegate the routing configuration/maintenance to independent, well known, more than ever powerful and failsafe devices: routers. Note that there is no need of different hardware but only of different (sub)interfaces for GW66s. Moreover: no need of separate hardware also for the intermediate router between H6s and GW66s, different instances of software can do the job. At GW64 there are no particular need, except the ability to perform IPv4/IPv6 translation, so it MUST be a so-called dual-stack router. Because H4s will send/receive packets from/to that device(s) on behalf of H6s, we need, at least, as many IPv4 "private" addresses as the number of reachable-H6s; much better an addresses pool as wide as the H6s network, 1:1 NAT is more easily-manageable in allocation of addresses. H4(s) are supposed to "see" H6(s) as they are H4(s), so no particular need at their charge, except the ability to communicate with GW64(s). Spinella Expires July 24, 2009 [Page 5] Internet-Draft IPv4 Multiplexing through IPv6 July 2009 3. Security considerations The author do not believe that introduction of IPv6-to-IPv6 NAT can cause problems or weakness nor increase the overall security; the IPv6 global-unicast addresses used in IPv6 segments are undistiguishable from any other IPv6 global-unicast address. 4. IANA Considerations Values from 0x0001 to 0xfffe in bits 81-96 of an IPv6 address are reserved for IPv4 adresses multiplexing. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden R. and Deering S., "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 5.2. Informative References [RFC1918] Rekhter Y., Moskowitz B., Karrenberg D., de Groot G.J. and Lear E., "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1925] Callon R., "The Twelve Networking Truths", RFC 1925, April 1st, 1996 6. Acknowledgements To Nuria Molto', for her endless support in review and suggestions. 7. Author's Addresses Alessandro Spinella Communication Valley s.p.a. Strada Budellungo,2 - 43100 Parma, Italia Phone: +39 0521 498022 EMail: a.spinella@communicationvalley.it http://www.rfc1925.net Comments are solicited and should be addressed to the author. Spinella Expires July 24, 2009 [Page 6]