Internet DRAFT - draft-azcorra-ipv64
draft-azcorra-ipv64
Network Working Group A. Azcorra
Internet-Draft A. Garcia-Martinez
Expires: September 6, 2002 M. Bagnulo
UC3M
March 8, 2002
Internet Protocol, Version 64 (IPv64) Specification
draft-azcorra-ipv64-04
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 September 6, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies an IPv6 protocol extension that allows IPv6
packets to be backward compatible with IPv4. An IPv6 packet
encapsulated in IPv4 in this way (called IPv64) would be processed as
native IPv6 by IPv64 routers, and at the same time, in case there is
an IPv4-only router in the path, it will be processed as IPv4.
Consequently, it is possible to have native end-to-end IPv6
communication, with IPv6 processing at IPv64 routers, through a path
that contains some IPv4-only routers.
Protocol conversion from/to IPv6 to/from IPv64 can be made by local
Azcorra, et al. Expires September 6, 2002 [Page 1]
Internet-Draft IPv64 Specification March 2002
routers at both ends, and therefore the advantages of IPv64 are
achieved with standard native IPv6 hosts.
Azcorra, et al. Expires September 6, 2002 [Page 2]
Internet-Draft IPv64 Specification March 2002
1. Changes from previous version of the draft
Clarification on the usage of the standard IPv6 and IPv4 headers.
Specification of protocol conversion from/to IPv6 to/from IPv64 may
be made by local routers at both ends.
Extension header to keep the IPv4 header when doing transit through
IPv6-only networks.
Prototype implementation may be downloaded from:
matrix.it.uc3m.es/~ipv64
Azcorra, et al. Expires September 6, 2002 [Page 3]
Internet-Draft IPv64 Specification March 2002
2. Introduction
The intention of this document is to provide a complementary
transition mechanism to facilitate the migration from IPv4 to IPv6.
This additional transition mechanism would allow IPv6 to be backward
compatible with IPv4. Being backward compatible means that IPv6
packets encapsulated in IPv4 will be processed as IPv6 by IPv6
routers (and not according to the encapsulating IPv4 header), while
IPv4 routers will process them as IPv4 (according to the
encapsulating IPv4 header).
To distinguish in the remaining text of this document between plain
IPv4-tunneled IPv6 packets and IPv4-encapsulated IPv6 packets that
will be processed as IPv6 by IPv6 routers, the former will just be
called tunneled IPv6 packets, while the latter will be called "IPv64"
packets. IPv4 packets that do not carry an IPv6 packet will just be
called IPv4 packets.
The approach described in this document has the advantage that it
allows the communication between two IPv6 hosts with packets being
processed as IPv6 packets at IPv64 routers, and being processed as
IPv4 at IPv4-only routers. Therefore, it is possible to use routing
based on an IPv6 destination address (including all new types), use
IPv6 source routing, and use hop-by-hop extension headers at in-
transit IPv64 routers, while in-transit IPv4-only routers will still
route the packet correctly.
Current transition approaches work well to interconnect IPv6 islands
through IPv4 clouds. The IPv64 approach offers advantages for the
coming situation in which there will be an infrastructure composed of
a substantial amount of both IPv4 and IPv6 user and transit networks.
To achieve the aforementioned functionalities it is required that
IPv64 routers recognize IPv64 packets, distinguishing them from other
IPv4 packets, in order to process them as IPv6 packets.
2.1 Requirements
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.
Azcorra, et al. Expires September 6, 2002 [Page 4]
Internet-Draft IPv64 Specification March 2002
3. IPv64 Packet Format
The format of an IPv64 packet is the same as an IPv6 packet
encapsulated in IPv4, with the specific utilization of the IPv4
fields described in the following subsections.
3.1 IPv4 Total Length
This IPv4 field contains the total length of the IPv4 packet. This
field will be unchanged by IPv64 routers unless there is a
modification of the size of the enclosed IPv6 packet (i.e. because
of modifications of extension headers).
3.2 Bit 16 of the second word of IPv4 header
Bit number 16 of the second word of the IPv4 header (i.e. bit number
48, beginning with bit 0, of the header) will be called "IPv64
packet". This bit MUST be set to 1 to identify that this packet is
an IPv64 packet, and not a regular tunneled IPv6 packet. Regular
tunneled IPv6 packets will be processed as IPv4 at IPv64 routers.
This bit is currently unused under RFC 791 [4].
3.3 IPv4 Fragmentation Control Fields
These rules apply to IPv4 fields Identification, Do not Fragment
(DF), More Fragments (MF), and Fragment Offset.
IPv4 in-transit or source fragmentation of IPv64 packets is
undesirable because the second and subsequent fragments would not
contain the IPv6 headers. As IPv6 headers are not present, IPv64
routers in the path will only be able to process IPv64 fragments as
IPv4 packets, thus loosing the whole IPv6 network functionality.
Therefore, IPv4 fragmentation is not allowed.
The IPv4 DF bit MUST be set to one. The source node MUST provide an
appropriate mechanism to use an IPv4 packet size that MUST be below
the minimum IPv4 MTU in the path to each destination, in order to
avoid that the IPv64 packet be discarded.
A straightforward mechanism, although somehow inefficient in
transmission overhead, is to always use 576 octets as MTU. Other
more efficient mechanisms remain for further study.
In case the upper layer at the source desires to send a packet size
above the path MTU (e.g. to send a large UDP datagram), IPv6
fragmentation will be used.
As a consequence of the above discussion, IPv4 fields MF and Fragment
Azcorra, et al. Expires September 6, 2002 [Page 5]
Internet-Draft IPv64 Specification March 2002
Offset MUST always be set to zero.
3.4 IPv4 Time To Live
This IPv4 field will only be processed by IPv4-only routers. IPv64
capable routers MUST NOT modify this field. IPv64 capable routers
MUST modify the Hop Limit field in the enclosed IPv6 header.
3.5 IPv4 Header Checksum
In case an IPv64 capable router modifies a field in the IPv4 header,
then the checksum will have to be recalculated. Examples of cases in
which an IPv64 capable router has to modify a field in the IPv4
header are the modification of a hop-by-hop extension header (that
implies a modification in the IPv4 Total Length field), or the
remarking of the IPv4 TOS field at a Differentiated Services IPv64
edge router.
3.6 IPv4 Source and Destination addresses
These fields MUST contain a sufficiently close IPv4 source and
destination addresses for the IPv64 packet. A sufficiently close
address means that it is not required that the IPv4 packet be
addressed to the final destination, but rather to a place beyond
which it will be processed only by IPv64 capable routers (possibly
combined with IPv6-only routers).
The source IPv4 address has to be sufficiently close to the source
IPv6 address, while the destination IPv4 address has to be
sufficiently close to the destination IPv6 address.
For example, it is possible to have a domain with a border router
that only has one public IPv4 address in its interface, while there
are many IPv6 hosts and IPv64 routers internally. In this case the
public IPv4 address used by any host sending packets to any host
within that domain will be the one of the border router, so the
packets are correctly routed from anywhere in the Internet to the
border router. Beyond the border router the IPv4 address will be
ignored, as all routers are IPv64, and packets will be routed based
only on the IPv6 destination address field.
The destination address field in the IPv4 header and the IPv6 header
need not correspond to the same system and interface, but they must
be consistent, as described above. The same applies for the IPv4 and
IPv6 source address fields.
Azcorra, et al. Expires September 6, 2002 [Page 6]
Internet-Draft IPv64 Specification March 2002
3.7 IPv6 Extension Headers in IPv64 packets
IPv6 extension headers are allowed in IPv64 packets. The extension
headers are located, as in regular IPv6 packets, following the IPv6
header, and with the same structure and semantics.
Azcorra, et al. Expires September 6, 2002 [Page 7]
Internet-Draft IPv64 Specification March 2002
4. Identification of IPv64 packets at IPv64 nodes
When an IPv64 router receives an IPv4 packet with value 4 in the
Internet Version field, it will need to know whether it is a native
IPv4 packet (including in this category pure tunneled IPv6 packets)
or an IPv64 packet, in order to decode and process it correctly.
The proposal for this function is that the currently unused bit in
the IPv4 header (that has been called "IPv64 Packet" field in this
document) be set to 1 in IPv64 packets. The IP specification in RFC
791 [4] indicates that even thought this bit is unused, it must be
set to 0. Therefore, IPv4 nodes sending IPv4 packets would set this
bit to 0, while IPv64 packets would have it set to 1. IPv64 routers
or destination nodes would use the value of this bit to distinguish
between incoming IPv4 packets and IPv64 packets.
This proposal is built on the assumption that all IPv4
implementations comply with RFC 791 [4], setting bit 16 of the second
word of the header to zero at the source, and ignoring its value when
processing the packet at routers and the destination node. As this
might not be the case, and the number of non-compliant
implementations could be significant, several alternative procedures
have been considered, but they are not described in this version of
the draft.
Azcorra, et al. Expires September 6, 2002 [Page 8]
Internet-Draft IPv64 Specification March 2002
5. Processing IPv64 packets at IPv64 nodes
An IPv64 source node needs to know, in addition to the source and
destination IPv6 of the packet to be built, the corresponding
sufficiently close IPv4 addresses. The procedure to obtain the
corresponding IPv4 addresses is described in the next section.
An IPv64 router receiving an IPv64 packet will first have to identify
it as such (see section 4 in this document). Once it has identified
the packet as IPv64, then it will process the packet as a native IPv6
packet, ignoring the fields of the IPv4 header, with the exception of
the TOS field, whose value is used instead of the one from Traffic
Class field (IPv4 remarking is acceptable). Once the packet has been
processed as an IPv6 packet, and the outgoing IPv6 packet has been
constructed, the outgoing IPv4 header will be constructed. The
outgoing IPv4 basic header (i.e. without the options field) will be
the same as the incoming one, with the following exceptions:
o Total Length: it will be recalculated if the length of the IPv6
enclosed packet has been modified (e.g. routing header).
o Type Of Service: it will be modified in case this is an edge
router and remarking of the DSCP field is needed. In this case,
the value of the outgoing DSCP field will be set according to the
Differentiated Services specification.
o IPv4 addresses: only modified if NAT is being performed. The
combined usage of IPv64 and IPv4 NAT is left for further study.
o Checksum: it will be recalculated if the incoming IPv4 header has
been modified.
Therefore, at an IPv64 router the fields of the IPv4 header in the
incoming IPv64 packet are used only to:
1. Identify the packet as an IPv64 packet and not a plain IPv4
packet.
2. The Traffic Class value in the incoming IPv6 header has to be
ignored, and its value be taken from the TOS octet of the IPv4
header. Notice that an IPv4 edge router performing remarking
would only remark the DSCP in the IPv4 TOS field.
3. Generate the appropriate IPv4 header in the outgoing IPv64
packet.
In the case of direct delivery of the IPv64 packet to its IPv6
destination, the address resolution function MUST be performed first
Azcorra, et al. Expires September 6, 2002 [Page 9]
Internet-Draft IPv64 Specification March 2002
using the IPv6 destination address.
Azcorra, et al. Expires September 6, 2002 [Page 10]
Internet-Draft IPv64 Specification March 2002
6. IPv64 Protocol Translation
IPv64 packet may transit correctly through IPv64 networks, IPv6 dual-
stack networks and IPv4-only networks, but may not interoperate with
IPv6-only nodes. For this reason, protocol conversion between IPv6
and IPv64 has been introduced.
Protocol translation may be used to avoid modifying the end-systems
in order to make them IPv64 compliant. In this scenario, protocol
translation would be provided at the IPv64 router with a direct
delivery capacity to the IPv6-only end-system. Therefore, IPv6-only
hosts would communicate with their local router using native IPv6,
while all the remaining end to end path would be performed with an
IPv64 packet generated at the local router. An IPv64 router with
IPv6 hosts connected to one of its interfaces can be configured to
perform protocol translation at that interface. This means that the
router will translate incoming IPv6 packets from that interface to
IPv64 packets, and IPv64 packets directed to a host on that interface
will be translated to native IPv6.
Protocol translation may also be used to perform transit of IPv64
packets through an IPv6-only network, without the need to perform
tunneling of IPv64 packets within IPv6 packets. Routers at both ends
of the IPv6-only network would perform protocol translation to/from
IPv64 from/to native IPv6.
6.1 Protocol translation from IPv64 to IPv6
Translating an IPv64 packet into an IPv6 packet is made by suppresing
the IPv4 header from the IPv64 packet. However, it is mandatory to
keep the IPv4 header information within the packet in order to allow
an immediate IPv6 to IPv64 translation of the packet, as it might be
needed further in the path to perform the reverse translation (IPv6
to IPv64).
In order to keep the IPv4 header information of the IPv64 packet
within the native IPv6-only packet, a specific extension header is
proposed. The extension header would allow that the IPv4 header
information is available if translation back to IPv64 is needed,
while it would allow correct processing at the destination IPv6 host
if it receives the native IPv6 packet. The detailed coding of the
IPv4 information required in the extension header is left for further
study.
6.2 Protocol translation from IPv6 to IPv64
Protocol translation from IPv6 to IPv64 requires that the IPv64
router has an implemented function that obtains the sufficiently
Azcorra, et al. Expires September 6, 2002 [Page 11]
Internet-Draft IPv64 Specification March 2002
close IPv4 addresses associated to both the IPv6 source and
destination. This function is the same as the one required in native
IPv64 end-systems to be able to generate the IPv64 packet from the
IPv6 source and destination addressing information.
This function is not needed in all IPv64 routers. Typically, it will
be installed in those interfaces of those IPv64 routers that have
IPv6-only hosts connected, or in those interfaces of those IPv64
routers that connect to an IPv6-only network to perform transit
through it.
This function has also to be installed in an IPv64 router that needs
to produce its own IPv64 traffic (e.g. to communicate directly with
a host or with another router).
In the particular case of translating an IPv6 packet that has been
produced from a previous translation of IPv64 to IPv6, the IPv4
addresses are kept in a specific IPv6 extension header (see the
previous sub-section). In this case, it is trivial to obtain the
required sufficiently close IPv4 source and destination addresses
because they are contained in the packet to be translated.
In the remaining situations, the generation of an IPv4 address from
an IPv6 address will be made by applying a combination of
complementary (not alternative) procedures. Notice that the relation
is not biyective but inyective. This is, several IPv6 addresses will
produce the same "sufficiently close" public IPv4 address. For this
reason, the implementation of the function will be based on
associating an IPv4 address to an IPv6 prefix. The association of an
IPv4 address to a single IPv6 address is just a particular case,
which is not excluded, but that will not be the most frequent case.
The complementary procedures to be used are the following:
1. Configured Table: the system has a table in which each entry
contains an IPv6 address/prefix, and its associated sufficiently
close IPv4 address. The system will perform table lookup of the
desired IPv6 address to find an applicable table entry that
renders the corresponding public IPv4 address. This procedure is
suitable for the source address (that will be locally known), and
for some cases of destination addresses, but it will not serve in
the general case for any IPv6 destination address.
2. Backward learning: the system will learn sufficiently close
destination IPv4 addresses by inspecting the IPv4 and IPv6 source
addresses of IPv64 packets that are received by it. This method
is particularly suitable for information servers, in which the
system will normally send packets that are responses to incomming
packets. By performing backward learning the system will always
Azcorra, et al. Expires September 6, 2002 [Page 12]
Internet-Draft IPv64 Specification March 2002
have the correctly resolved IPv4 address to the IPv6 destination
that it wants to respond to.
3. IPv6 addresses with embedded IPv4 address: the system obtains the
sufficiently close IPv4 address from the IPv6 address itself.
This is applicable, for example, to IPv6 addresses that code an
IPv4 address.
4. Cached table: the system will maintain a cached table of
previously resolved associations. The table will have the same
structure as the configured table above (pairs of an IPv6
address/prefix plus its associated IPv4 address). As in any
cached table, entries will be suppressed either by timeout (to
allow automatic update of changing situations), or by removing
the oldest ones when the cache size-limit is reached.
5. DNS look up: performing DNS lookup of a specific entry defined
for this purpose. Notice that it is not needed to have a
specific entry for each destination, and is enough to have a
sufficiently close IPv4 address for a whole domain (e.g. as done
for e-mail gateways). It must be taken into account that to
perform DNS look up it is required first to perform reverse DNS
lookup, to obtain the name from the IPv6 address. This subject
remains for further study.
Protocol translation must be made guaranteeing the requirement
already described that IPv4 fragmentation of IPv64 packets MUST NOT
take place. This implies that the IPv6 MTU being used MUST be, at
most, 20 octets smaller than the actual IPv4 MTU of the path. This
subject remains for further study.
Azcorra, et al. Expires September 6, 2002 [Page 13]
Internet-Draft IPv64 Specification March 2002
7. Other Processing Considerations
7.1 Processing IPv64 packets at IPv4-only nodes
Plain IPv4 nodes will treat IPv64 packets as IPv4 packets, as they
can not distinguish IPv64 packets from IPv4 packets. It is required
that IPv4 nodes comply with RFC 791, in the sense that the unused bit
of the header (bit number 48, beggining with bit 0) MUST be forwarded
unmodified.
A plain IPv4 end system that receives an IPv64 packet will pass all
data after the IPv4 header to the corresponding upper layer protocol
entity identified in the Protocol field of the IPv4 header. If the
upper layer protocol entity is an IPv6 protocol entity, then the
encapsulated packet would be correctly processed.
7.2 Processing IPv64 packets at IPv6-only nodes
IPv6-only nodes cannot process regular IPv64 packets as they begin
with the IPv4 header. For this purpose, the function of protocol
translation to/from IPv6 has been detailed in the corresponding
section. By performing protocol translation at the edges of IPv6-
only networks it is possible to perform transit through them, without
loosing any of the advantages of IPv64.
7.3 Processing IPv64 packets at IPv6 dual-stack nodes
When performing transit through an IPv6 dual-stack network, two
approaches are possible.
The first approach is to just forward the IPv64 packet into the
network. In this case, the IPv6 dual-stack nodes will treat IPv64
packets as IPv4 packets, as they can not distinguish IPv64 packets
from IPv4 packets.
The second approach is to perform protocol translation, as performed
when doing transit through an IPv6-only network. In this case the
packet would be processed within the network as IPv6, and protocol
translation back to IPv64 would be needed at the outgoing edge of the
transit network.
7.4 Firewalls and other protocol functions
The impact of Firewalls, NAT, ICMP diagnostics, ECN, path MTU
discovery and other functions in relation to IPv64 remain for further
study.
Azcorra, et al. Expires September 6, 2002 [Page 14]
Internet-Draft IPv64 Specification March 2002
8. Conclusions
The IPv64 transition mechanism described in this document is
compatible with other transitions mechanisms based on NAT and on
different tunneling approaches, and might be used in conjunction with
them.
As more dual-stack IPv6 routers incorporate these functions (becoming
IPv64 routers), then more IPv64 packets will be processed as IPv6
instead of as IPv4, smoothly migrating the network functionality to
IPv6.
Current transition approaches work well to interconnect IPv6 islands
through IPv4 clouds. The advantages of the IPv64 approach will arise
in the coming situation in which there will be an infrastructure
composed of highly interconnected IPv4 and IPv6 user and transit
networks.
IPv64 requires modifications in the procedures of IPv6
implementations in order to recognize and process IPv64 packets as
IPv6, instead of forwarding them as IPv4. However, these changes
need not be deployed elsewhere, and might be deployed just at some
routers without affecting the functionality of the network.
The implementation complexity to upgrade a dual-stack IPv6 router to
become an IPv64 transit (core) router is negligible, compared with
the complexity of the dual-stack sytem itself. The complexity of the
protocol translation functions is also considered low. The per-
packet computational cost of pure IPv6 to IPv64 protocol conversion
makes it suitable only to be deployed in the local routers of native
IPv6-only hosts local networks.
Azcorra, et al. Expires September 6, 2002 [Page 15]
Internet-Draft IPv64 Specification March 2002
9. Acknowledgements
This work has used valuable comments received from Tony Hain, Brian
E. Carpenter, and Svend Moeller Nielsen. Prototype implementation
and tests have been performed by Fernando Anton.
This work has been partly supported by the European Union, under IST
projects GCAP and LONG, and also under COST 263 "Quality of Future
Internet Services".
Azcorra, et al. Expires September 6, 2002 [Page 16]
Internet-Draft IPv64 Specification March 2002
References
[1] Deering et. al., S., "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[2] Nichols et. al., K., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC
2474, December 1998.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[4] Postel, J., "Internet Protocol", RFC 791, September 1981.
[5] Srisuresh , P. and K. Egevang , "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001.
[6] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
Authors' Addresses
Arturo Azcorra
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: +34 91 6248778
EMail: azcorra@it.uc3m.es
URI: http://www.it.uc3m.es
Alberto Garcia-Martinez
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es
Azcorra, et al. Expires September 6, 2002 [Page 17]
Internet-Draft IPv64 Specification March 2002
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: +34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Azcorra, et al. Expires September 6, 2002 [Page 18]
Internet-Draft IPv64 Specification March 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Azcorra, et al. Expires September 6, 2002 [Page 19]
