Internet DRAFT - draft-nena-ip4-ip6-mux
draft-nena-ip4-ip6-mux
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
rfc1925.net">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]
