Next Generation Transition WG A. Azcorra
Internet Draft U. Carlos III de Madrid
Expires: February 9, 2002
August 10, 2001
Internet Protocol, Version 64 (IPv64) Specification
draft-azcorra-ipv64-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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 February 9, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document specifies an IPv6 protocol modification that allows the
"clonation" of IPv4 packets. An IPv6 packet sent as a "clonic" IPv4
packet is undistinguishable from plain IPv4 packets to IPv4-only
routers. Therefore, IPv4-only routers will be able to process and
forward IPv6 packets that are sent as IPv4 "clones", allowing native
end-to-end IPv6 communication through IPv4-only routers, without the
usage of tunneling.
A. Azcorra Expires February 9, 2002 [Page 1]
INTERNET-DRAFT IPv64 Specification August 10, 2001
Table of Contents
1. Introduction................................3
1.1. Requirements..............................4
2. IPv6 Header Format..........................4
2.1. Version...................................4
2.2. Flow Label (High).........................5
2.3. Differentiated Services Code Point........5
2.4. IPv6 Source Address.......................5
2.4.1. Fragmentation Control Sub-Fields........6
2.4.2. Time To Live............................6
2.4.3. Protocol................................6
2.4.4. Header Checksum.........................7
2.4.5. IPv4 Source and Destination addresses...7
2.5. IPv6 Destination Address..................7
2.6. Flow Label (Low)..........................7
2.7. Total/Payload Length......................8
2.8. Next Header...............................8
2.9. Hop Limit.................................8
3. IPv64 Source Address Extension Header ... 8
4. IPv4 Options in IPv64 packets...............8
5. Firewalls and other protocol functions......9
A. Azcorra Expires February 9, 2002 [Page 2]
INTERNET-DRAFT IPv64 Specification August 10, 2001
1. Introduction
This document is motivated by growing concern about the time that is
taken for widespread usage of the IPv6 protocol. It is considered that
time is a critical variable, and unless the next version of a protocol
is adopted before a certain time, the protocol will change to
incorporate "functional improvements". This process will repeat
preventing the real widespread adoption of the protocol.
Transition mechanisms from IPv4 to IPv6 were taken into account for
the definition of IPv6, and yet I consider that transition mechanisms
not good enough, together with other non-technical issues, are
hindering the adoption of IPv6.
With the intention of facilitating the migration from IPv4 to IPv6,
this document specifies an IPv6 protocol modification that allows the
"clonation" of IPv4 packets. An IPv6 packet sent as a "clonic" IPv4
packet is undistinguishable from plain IPv4 packets to IPv4-only
routers. Therefore, IPv4-only routers will be able to process and
forward IPv6 packets that are sent as IPv4 "clones", allowing native
end-to-end IPv6 communication through IPv4-only routers.
To distinguish in the remaining text of this document plain IPv6
packets from IPv6 packets sent as "cloned" IPv4 packets, the former
will be called IPv6 packets, while the latter will be called "IPv64"
packets.
This approach has the advantage to allow the communication between two
IPv6 hosts through routers that may be either IPv4-only or IPv6
capable, without using tunneling and protocol conversion. Tunneling
and protocol conversion have well-known disadvantages that make it
preferable to use a "native" solution. Moreover, the approach proposed
in this document makes it possible that IPv6 routers in the path
process IPv64 packets as IPv6 packets, obtaining the benefits of in-
transit IPv6 routers that cannot be obtained when using tunneling.
Another advantage is that this proposal makes it easier to deploy IPv6
applications in an IPv4-only host. The reason is that it is not
required to modify the IPv4 stack, that usually is in the OS kernel,
and it is only needed the installation of a package over a raw IP
socket.
It is then required to define an IPv6 packet format that allows the
"clonation" of an IPv4 packet. This can be done by redesigning the
location of fields in the IPv6 header format to better fit the IPv4
header. It is also required to introduce the concepts of data
polymorphism and active networks. This concept allow the different
interpretation of a given data item depending on the context. In our
case, this concepts will be applied mainly to the interpretation of
the content of the address field, and in a lesser extent to other
fields.
A. Azcorra Expires February 9, 2002 [Page 3]
INTERNET-DRAFT IPv64 Specification August 10, 2001
1.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.
2. IPv6 Header Format
The proposed IPv6 header format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| FL H | DiffServ CP | Total/Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Label (Low 16) | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Version
This field contains the 4-bit Internet Protocol version number.
Acceptable values for this field are 4 and 6.
Value 6 MUST be used when the end to end IPv6 compatibility is
guaranteed, either because the destination host and all routers in
transit are IPv6 capable, or through other compatibility mechanisms.
Value 4 MUST be used when the destination host is IPv6 capable (either
native or through the installation of an additional layer) but it is
not guaranteed that there is end to end IPv6 compatibility (typically
because there are IPv4-only routers in the path). In this case, the
packet will be called "IPv64" to distinguish it from plain IPv6
packets.
A. Azcorra Expires February 9, 2002 [Page 4]
INTERNET-DRAFT IPv64 Specification August 10, 2001
2.2. Flow Label (High)
This field contains the four high order bits of the 20 bit flow label
tag.
In IPv6 packets its value is determined by the source node, as a side
effect of selecting the appropriate flow label value as specified in
RFC 2460.
In IPv64 packets this field MUST be set to five. The reason is that
these four bits correspond to the Internet Header Length field in IPv4
packets. Therefore, in order to allow that an IPv4-only router
correctly processes this IPv64 packet, the value of the Internet
Header Length field read by the IPv4-only router must be five.
2.3. Differentiated Services Code Point
The value of this field should be coded as specified in RFC 2474.
This subject remains for further study. An alternative design that
could have implementation advantages would be to use a reserved value
in this field to distinguish IPv64 packets from IPv4 packets.
2.4. IPv6 Source Address
In IPv6 packets, this field contains the 128-bit address of the
originator of the packet, as specified in RFC 2460. Therefore, the
remaining part of this sub-section applies only to IPv64 packets.
In IPv64 packets, this field contains the IPv4 "clonic" header as
specified in RFC 791, including IPv4 source and destination addresses.
For this reason, in IPv64 packets this field is structured in the
following sub-fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The values of these sub-fields will be selected, modified, and
interpreted according to the specifications contained in RFC 791 et
seq., with the modifications specified in the following sub-sections.
A. Azcorra Expires February 9, 2002 [Page 5]
INTERNET-DRAFT IPv64 Specification August 10, 2001
2.4.1. Fragmentation Control Sub-Fields
This applies to sub-fields Identification, Flags, and Fragment Offset.
Fragmentation of IPv64 packets is undesirable because the second and
subsequent fragments do not contain the IPv6 fields. As IPv6 fields
are not present, IPv6 routers in the path will only be able to process
IPv64 fragments as IPv4 packets, thus loosing all of the network IPv6
functionality. Therefore, the DF bit MUST always be set to one. The
source node MUST provide an appropriate mechanism to use a 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, although somehow inefficient in transmission,
mechanism is to always use 576 octets as MTU.
This aspect remains for further study.
2.4.2. Time To Live
This sub-field will only be processed by IPv4-only routers. IPv6
capable routers MUST not modify this sub-field. IPv6 capable routers
MUST modify the Hop Limit field.
This fact should be taken into account by the source node when
selecting the appropriate value for this field.
This aspect remains for further study, because alternative design
would be that IPv6 routers decrement both the TTL sub-field and the
Hop Limit fields.
2.4.3. Protocol
When an IPv4-only destination node receives an IPv64 packet, it will
pass its data to the higher-layer protocol entity specified in the
Protocol sub-field. For this reason, it is required that a specific,
and currently unused, value (e.g. value 101 decimal, see RFC 1700) be
assigned for IPv64 packets processing in IPv4-only nodes.
This field MUST be set to a specific, and currently unused, value. The
assignment of the said value is not the subject of this document.
The above assignment assumes that a suitable protocol entity will be
installed, possibly in user space of the SO, over an IPv4 raw socket.
This protocol entity may receive and send IPv64 packets, offering IPv6
service over it for IPv6 applications. The design of this protocol
entity remains for further study.
When an IPv6 router or destination node receives a packet with value 4
in the Internet Version field, it will need to know whether it is a
native IPv4 packet or an IPv64 packet, in order to decode and process
it correctly. The content of the Protocol sub-field could be used for
this purpose: if the received value matches the specifically assigned
A. Azcorra Expires February 9, 2002 [Page 6]
INTERNET-DRAFT IPv64 Specification August 10, 2001
one, it is an IPv64 packet; otherwise, it is a plain IPv4 packet. This
subject remains for further study because an alternative, or
complementary, design that could have implementation advantages at
IPv6 routers would be to use another field to distinguish between
IPv64 packets and IPv4 packets (e.g. a reserved value in DSCP).
2.4.4. Header Checksum
This sub-field will only be recalculated by IPv4-only routers, as they
will decrement the TTL sub-field. IPv6 capable routers MUST not modify
this sub-field, as they do not change any value in the "clonic" IPv4
header. An exception to this rule is the usage of IPv6 options that
may require the modification of values in the IPv4 sub-header (e.g. an
IPv6 router performing IPv4 NAT.)
2.4.5. IPv4 Source and Destination addresses
These sub-fields MUST contain the IPv4 source and destination
addresses of the IPv64 packet.
Source IPv4 address is mandatory as the IPv6 source address can not be
sent because the field is being used for IPv4 clonation. It is also
mandatory because an IPv4-only router discarding the packets needs it
in order to send the diagnostic ICMP packet back to the source.
Destination IPv4 address is mandatory (in addition to the destination
IPv6 address) as it is required by the IPv4-only routers for routing
purposes.
Notice that IPv64 packets only make sense during the transition
period, during which every node is required to have an assigned IPv4
address.
2.5. IPv6 Destination Address
128-bit address of the intended recipient of the packet (possibly not
the ultimate recipient, if a Routing header is present), as specified
in RFC 2460.
2.6. Flow Label (Low)
This field contains the sixteen low order bits of the 20 bit flow
label tag.
In IPv6 packets its value is determined by the source node, as a side
effect of selecting the appropriate flow label value as specified in
RFC 2460.
In IPv64 packets its value is determined by the source node, as a side
effect of selecting the appropriate flow label. The selection of the
value of the flow label will be done according to the specifications
of RFC 2460, but it MUST be taken into account that for IPv64 packets
A. Azcorra Expires February 9, 2002 [Page 7]
INTERNET-DRAFT IPv64 Specification August 10, 2001
the four high order bits of the label are set to five, and only the
sixteen low order bits (coded in this field) can be assigned freely.
2.7. Total/Payload Length
This field is a 16-bit unsigned integer.
In IPv6 packets it contains the Length of the IPv6 payload, i.e., the
rest of the packet following this IPv6 header, in octets. Note that
any extension headers present are considered part of the payload,
i.e., included in the length count, as specified in RFC 2460.
In IPv64 packets it contains the Total Length of the packet, as
specified in RFC 791. This definition allows compatibility with the
IPv4 field that is located in the same header position. Notice that it
implies the restriction that the maximum payload size of IPv64
datagrams is 40 octets smaller than the one of plain IPv6 datagrams.
However, this is considered a minor restriction.
2.8. Next Header
8-bit selector. Identifies the type of header immediately following
the IPv6 header. Uses the same values as the IPv4 Protocol field [RFC-
1700 et seq.]. The definition of this field is the same as the one
done in RFC 2460.
2.9. Hop Limit
8-bit unsigned integer. Decremented by 1 by each IPv6 node that
forwards the packet. The packet is discarded if Hop Limit is
decremented to zero.
3. IPv64 Source Address Extension Header
As IPv64 packets make use of the IPv6 Source Address Field to "clone"
the required fields of the IPv4 header, the packet may only carry its
source address in IPv4 format. To allow the transport of the source
address in IPv6 format it is recommended to define another Extension
Header in the IPv6 protocol. This new Extension Header would allow to
carry the 16 byte IPv6 source address in IPv64 packets that require
it.
The definition of the said Extension Header is not a subject of this
document and is left for further study.
4. IPv4 Options in IPv64 packets
Under the definition of IPv64 in this document, it is not possible to
use IPv4 options with in IPv64 packets. This might be a limitation,
for example when wishing to select IPv4 source routing options. An
alternative design to the one proposed would be to allow IPv4 options.
In this case, the Flow Label High field should contain the appropriate
A. Azcorra Expires February 9, 2002 [Page 8]
INTERNET-DRAFT IPv64 Specification August 10, 2001
value that matches the length of the options portion of the IPv4
header. The IPv6 Destination Address field would then be located, as
in this proposal, at the beginning of the Data field, but in a
variable position that would depend on the length of the IPv4 options
part. Having the IPv6 Destination Address field in a variable position
is considered a severe drawback for implementation reasons.
The possibility of allowing IPv4 options in IPv64 packets remains for
further study.
5. Firewalls and other protocol functions
A first problem that may be caused by IPv4-only firewalls is the
filtering of ICMP messages that is frequently done to avoid denial of
service attacks. This might cause difficulties for source nodes to
determine the end-to-end packet size to use for a given destination,
because ICMPv4 diagnostic messages corresponding to a non-fragmentable
packet that has been discarded will be filtered.
Another problem derived from IPv4-only firewall usage is that they
will consider all IPv6 traffic as belonging to the protocol value
assigned for IPv64.
The impact of IPv6 routing header, IP Sec, NAT, ICMP diagnostics, and
other functions over IPv64 remains for further study.
A. Azcorra Expires February 9, 2002 [Page 9]
INTERNET-DRAFT IPv64 Specification August 10, 2001
References
[RFC-2460] Deering, S., et. al., "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[RFC-2474] Nichols, K., et. al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
Authors' Addresses
Arturo Azcorra
Universidad Carlos III de Madrid
Av. Universidad 30
28911 Leganes (Madrid)
SPAIN
Email: azcorra@it.uc3m.es
A. Azcorra Expires February 9, 2002 [Page 10]
INTERNET-DRAFT IPv64 Specification August 10, 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
A. Azcorra Expires February 9, 2002 [Page 11]