Internet-Draft Alessandro Spinella Intended status: Proposed Standard Communication Valley Expires: March 9, 2009 September 3, 2008 Never Ending Network Addresses: IPv4 Multiplexing trought IPv6 draft-nena-ip4-ip6-mux-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 March 9, 2009. 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 March 9, 2009 [Page 1] Internet-Draft IPv4 Multiplexing trought IPv6 March 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) trought "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. Use of "public" addresses pools to NAT "private" addresses lead to unreachable public resources, a very poor/unscalable result. 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 March 9, 2009 [Page 2] Internet-Draft IPv4 Multiplexing trought IPv6 March 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 March 9, 2009 [Page 3] Internet-Draft IPv4 Multiplexing trought IPv6 March 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 management 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. (*) 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 | +--------+-----------------------+---------------------+----------+ (*) Because "IPv4-Compatible IPv6 Address" are deprecated [RFC4291] them MAY be used, but "IPv4-Mapped IPv6 Address" are recommended. Spinella Expires March 9, 2009 [Page 4] Internet-Draft IPv4 Multiplexing trought IPv6 March 2009 2.3. CNID structure The 16 bit CNID can be used as a flat space or structured one, as management-network-manager like; 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 March 9, 2009 [Page 5] Internet-Draft IPv4 Multiplexing trought IPv6 March 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 This document has no actions for IANA. 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 rewiew 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 March 9, 2009 [Page 6] Internet-Draft IPv4 Multiplexing trought IPv6 March 2009 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Spinella Expires March 9, 2009 [Page 7]