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]