A. Azcorra Internet Draft Univ. Carlos III Document: draft-azcorra-ipv64-02.txt de Madrid Expires: February 9, 2002 September 2, 2001 Internet Protocol, Version 64 (IPv64) Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document specifies an IPv6 protocol extension that allows IPv6 tunneling to be backward compatible with IPv4. An IPv6 packet tunneled in this way would be processed as native IPv6 by IPv6 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 IPv6 routers, through a path that contains some IPv4- only routers. Another feature currently under study would allow that IPv4-only hosts be capable of correctly receiving and processing IPv6 packets that are tunneled in this way. Therefore, IPv6 routers will process the packet as an IPv6 packet, IPv4-only routers will process it as IPv4, and the destination IPv4-only node will correctly process it as an IPv4 packet. A. Azcorra Informational - Expires February 9, 2002 1 INTERNET DRAFT IPv64 Specification September 2, 2001 Table of Contents 1. Changes from previous version of the draft......................3 2. Introduction....................................................3 3. IPv64 Packet Format.............................................4 4. IPv6 Extension Headers in IPv64 packets.........................6 5. Sending IPv64 packets to IPv4-only destinations.................6 6. Identification of IPv64 packets at IPv6 nodes...................9 7. Processing IPv64 packets at IPv6 nodes.........................10 8. Firewalls and other protocol functions.........................11 9. Conclusions....................................................11 10. Acknowledgements..............................................11 A. Azcorra Informational - Expires February 9, 2002 2 INTERNET DRAFT IPv64 Specification September 2, 2001 1. Changes from previous version of the draft A major modification on the approach taken on the header format has been made: the IPv6 header fields are not relocated, and instead, IPv4 tunneling is used. 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 that IPv6 be backward compatible with IPv4. Being backward compatible means that tunneled IPv6 packets 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) as it is done now. To distinguish in the remaining text of this document between plain IPv4-tunneled IPv6 packets and IPv4-tunneled 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 a tunneled 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 IPv6 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 IPv6 routers, while in-transit IPv4-only routers will still route the packet correctly. Another feature, currently under study, is that an IPv4-only destination host (without any IPv6 software installed) receives and correctly processes an IPv64 packet. Obviously, in this case it is not possible to use the end-to-end extension headers of IPv6, but it is still possible to get the advantages of IPv6 in-transit processing, and to logically assign a public destination (not source) IPv6 address to the host (in addition to a private or public IPv4 address). To achieve the aforementioned functionalities it is required that IPv6 nodes 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. A. Azcorra Informational - Expires February 9, 2002 3 INTERNET DRAFT IPv64 Specification September 2, 2001 3. IPv64 Packet Format The format of an IPv64 packet is the same as an IPv6 packet tunneled over IPv4 with the following modifications on the usage of the IPv4 fields. 3.1 IPv4 Total Length This IPv4 field contains the total length of the IPv4 packet. This field will be unchanged by IPv6 routers unless there is a modification of the size of the enclosed IPv6 packet (e.g. because of modifications of extension headers). 3.2 Bit 16 of the IPv4 header Bit number 16 of the IPv4 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 IPv6 routers. 3.3 IPv4 Fragmentation Control Fields These rules apply to IPv4 fields Identification, Do not Fragment (DF), More Fragments (MF), and Fragment Offset. In-transit fragmentation of IPv64 packets is undesirable because the second and subsequent fragments would not contain the IPv6 headers. As IPv6 headers 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, in-transit fragmentation is not allowed. The IPv4 DF bit MUST 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 overhead, mechanism is to always use 576 octets as MTU. In case the source desires to send a packet size above the path MTU (e.g. to send a large UDP datagram), fragmentation at the source node will be performed. For IPv6-capable destinations (either native or extended at the upper layer), IPv6 fragmentation will be used. Therefore fields MF and Fragment Offset MUST be both set to zero. A. Azcorra Informational - Expires February 9, 2002 4 INTERNET DRAFT IPv64 Specification September 2, 2001 3.4 IPv4 Time To Live This IPv4 field will only be processed by IPv4-only routers. IPv6 capable routers MUST NOT modify this field. IPv6 capable routers MUST modify the Hop Limit field in the IPv6 header. This fact should be taken into account by the source node when selecting the appropriate value for both fields (TTL and Hop Limit). This aspect remains for further study, because an alternative design would be that IPv6 routers decrement both the TTL sub-field and the Hop Limit fields. However, this approach has the disadvantage to require a modification of the contents of the IPv4 header at all IPv6 routers, instead of just forwarding it unchanged whenever possible. 3.5 IPv4 Header Checksum In case an IPv6 capable router modifies a field in the IPv4 header, then the checksum will have to be recalculated. Examples of cases in which an IPv6 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 IPv6 edge router. 3.6 IPv4 Source and Destination addresses These sub-fields MUST contain a sufficiently close IPv4 source and destination addresses of 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 IPv6 routers. 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 routers internally. In this case the 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 IPv6, and packets will be routed based only on the IPv6 destination address field. Notice that it is possible to have IPv4- only hosts with an IPv6 address "virtually" assigned to them (see the section "Sending IPv64 packets to IPv4-only destinations"). 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. A. Azcorra Informational - Expires February 9, 2002 5 INTERNET DRAFT IPv64 Specification September 2, 2001 4. 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. 5. Sending IPv64 packets to IPv4-only destinations This feature remains for further study. What follows is the current state of the design. The objective of this feature is to allow that an IPv4-only destination node receives, and correctly processes, an IPv64 packet even without any specific IPv6 software installed. This would allow the advantages of IPv6 in-transit processing (IPv6 destination address being assigned to the IPv4-only node, routing extension header and hop-by-hop extension headers, etc) while sending packets to an IPv4-only host. The basic idea is to encode the IPv6 header of IPv64 packets as IPv4 options of the encapsulating IPv4 packet. To achieve this feature, a number of changes are required on the usage of some fields that have been described in the previous sections. This refinement of the IPv64 format will be called "IPv4-compatible" format. This feature is built on the assumption that IPv4 implementations (router or host) that detect an unrecognized option number will ignore the option and process the packet normally, instead of discarding the packet. The main disadvantage of using the IPv4-compatible format is that it requires to use the IPv4 options field, which on some IPv4 routers would imply processing the packet on the slow path. Another disadvantage is that higher four bits of the Flow Label field can not be used. Notice that the following changes in field usage would only be required when sending an IPv64 packet to an IPv4-only destination node, and the usage would be as described up to now when the destination is an IPv6-capable node. 5.1 IPv4 Internet Header Length Field The IPv4 IHL field of IPv64 packets MUST be set to 15 decimal so as to consider the IPv6 header as included into the Options part of the IPv4 header. 5.2 IPv6 Traffic Class Field The value of this field is combined with the value in the IPv6 Internet Protocol Field and the value in the IPv6 Flow Label Field A. Azcorra Informational - Expires February 9, 2002 6 INTERNET DRAFT IPv64 Specification September 2, 2001 in order to resemble the first two octets in the IPv4 Options field. Therefore, its value MUST be set to 11110001 binary. This usage does not prevent the utilization of Differentiated Services, because when processing any IPv64 packet at an IPv6 router the value contained in the IPv4 TOS field MUST be used as the value to apply the correct PHB to this packet. In case the router is an edge router and remarking is needed, then the corresponding value MUST be coded in the TOS field of the IPv4 header of the outgoing IPv64 packet, but MUST NOT be coded in the IPv6 Traffic Class Field. 5.3 IPv6 Flow Label Field The highest order four bits of the IPv6 Flow Label Field MUST be set to binary 0100. The remaining bits of the IPv6 Flow Label Field may be set to any value that the source node decides. 5.4 Resulting IPv4 Options Field The above values result in the following coding for the IPv4 Option Type and Option Length: Type Length +--------+--------+ |01101111|00010100| +--------+--------+ Type: Copied flag: 0 (fragments must not carry the option) Option class: 11 (Reserved for future use) Option number: 01111 (15 decimal) Length: 0101000 (40 decimal) The selection of the option class (Reserved) is a side effect of the coding of the Internet Protocol Version Field (value 0110 binary). The selection of the option number 15 decimal has been done taking into account that the high-order bit has to be zero (the last bit in the Internet Version Field), and therefore it is not possible to select a currently unassigned number. The Assigned Numbers RFC states that value 15 is reserved for VerSteeg. In case it is not possible to use instead value 15 for this feature, it would be needed to vacate other option number below 15. If this is not considered possible, the only other solution would be to code an odd value (e.g. 7 decimal) in the Internet Protocol Version Field, which does not seem a very desirable solution. The remaining 38 octets in the IPv4 options field consist of the IPv4 option data, and their value depends on the actual value of the IPv6 header, without further restrictions. A. Azcorra Informational - Expires February 9, 2002 7 INTERNET DRAFT IPv64 Specification September 2, 2001 5.5 IPv4 Protocol Field This field must carry the protocol identifier of the actual upper layer protocol data unit contained in the IPv6 packet payload, instead of a specific value to identify the enclosed IPv6 packet. 5.6 IPv4 Fragmentation fields In-transit IPv4 fragmentation is not permitted because it would not copy the IPv6 header, neither the IPv6 extension headers, to the fragments following the first one. For this reason, the DF bit MUST be set to 1. As IPv6 fragmentation may not be used in this case (the destination node is IPv4-only), IPv4 fragmentation will be needed when it is desired to send a payload that implies a datagram size above the path MTU. Then, source-node IPv4 fragmentation MUST be used, and therefore the values of the IPv4 fragmentation fields (Identification, MF and Offset) should be coded by the source node according to the fragmentation specification of IPv4 in RFC 791, taking into account the following aspect. IPv6 extension headers present in one, or more, of the fragments will be removed before the packet arrives to its final destination. Therefore their length MUST NOT be taken into account when calculating the value of the IPv4 Fragment Offset field in each fragment. This is, the values coded in the Fragment Offset field of the fragments MUST be calculated as in the standard RFC 791 way, taking into account only the IPv6 data payload, ignoring the existence of IPv6 extension header octets, in case they are present. 5.7 IPv6 Extension Headers End-to-end IPv6 extension headers can not be used because the destination is an IPv4-only node. IPv6 routing and hop-by-hop extension headers can be used as long as it is guaranteed that they will be removed by in-transit IPv6 routers, and will not arrive to the destination node. For routing headers, the IPv6 router MUST take into account the IPv4 header in the incoming IPv64 packet in order to generate a correct IPv4 header for the outgoing IPv64 packet. 5.8 IPv4 Options As the maximum variable part of the IPv4 header is used to carry the IPv6 header, then no IPv4 options may be used in IPv64 packets sent in IPv4-compatible format. A. Azcorra Informational - Expires February 9, 2002 8 INTERNET DRAFT IPv64 Specification September 2, 2001 6. Identification of IPv64 packets at IPv6 nodes When a native IPv6 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 first 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 indicates that even thought bit 16 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. Native IPv6 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, setting bit 16 to zero at the source, and ignoring its value when processing the packet at routers and destination node. As this might not be the case, and the number of non-compliant implementations could be relevant, several alternative procedures have been considered. These procedures are described in the following sub-sections. 6.1 Using the reserved IPv4 option number IPv64 packets sent as IPv4 compatible packets would have the specific option number (decimal 15 as stated above) reserved for this purpose. Therefore, IPv6 nodes could use this fact to detect IPv64 packets. Notice that this only applies to IPv64 packets sent in IPv4 compatible way. Consequently, either, a) ALL IPv64 packets are sent in IPv4 compatible format, or, b) another procedure is used to detect IPv64 packets sent in non-IPv4 compatible format. Alternative a) would extend the already mentioned disadvantages of the IPv4 compatible format to all IPv64 packets: processing in the slow path and restrictions on the use of the flow-label field. Alternative b) is feasible (see the next sub-section), but would require more instructions to implement the procedure of detecting formats. This procedure has to be applied to each and every packet, and is therefore somehow undesirable. 6.2 IPv4 Protocol field The content of the IPv4 Protocol field could be used to detect IPv64 packets sent in regular format (i.e. those that are not in IPv4- compatible format): when a packet that does not have option number A. Azcorra Informational - Expires February 9, 2002 9 INTERNET DRAFT IPv64 Specification September 2, 2001 15 set has the reserved value (e.g. 101) for IPv64 packets in the IPv4 Protocol field, then it is an IPv64 packet. 6.3 IPv4 DSCP value in the TOS Field The six-bit DSCP value in the IPv4 header could be assigned a reserved value to identify IPv64 packets. The disadvantage is that in this case Differentiated Services could not be used for IPv64 packets, as all of them would carry the specific DSCP value. 6.4 ECN bits in the Differentiated Services Field One of the two bits in the Differentiated Services Field that have been proposed to be used for ECN (see RFC 3022) could be used for this function. The obvious disadvantage is that in this case they could not be used for ECN. 7. Processing IPv64 packets at IPv6 nodes The IPv6 source node needs only to know the IPv6 address of the final destination and a sufficiently close IPv4 address. These values are reasonable static and independent of the network topological changes. An IPv6 router receiving an IPv6 packet tunneled over IPv4 will process it as it is done now. An IPv4 router receiving an IPv6 packet tunneled over IPv4 will process it as it is done now. An IPv6 router receiving an IPv64 packet will first have to identify it as such (see the corresponding section 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. 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: * Total Length: it will be recalculated if the length of the IPv6 enclosed packet has been modified (e.g. routing header). * 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. * IPv4 addresses: only modified if NAT functions are used. The combined usage of IPv64 and NAT is currently for further study. * Checksum: it will be recalculated if the incoming IPv4 header has been modified. A. Azcorra Informational - Expires February 9, 2002 10 INTERNET DRAFT IPv64 Specification September 2, 2001 Therefore, at an IPv6 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 TOS field. 3. Generate the corresponding IPv4 header in the outgoing IPv64 packet. The address resolution function MUST be performed using the IPv6 destination address. This would allow that an IPv4-only host with only a private IPv4 address receives IPv64 packets addressed to a public IPv6 address assigned to it, as long as an IPv6-capable router is attached to its same subnetwork. 8. Firewalls and other protocol functions The impact of NAT, ICMP diagnostics, ECN, and other functions over IPv64 remains for further study. 9. Conclusions The IPv64 transition mechanism described in this document is compatible with NAT and tunneling approaches, and might be used in conjunction with them. 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 global, and might be deployed at some IPv6 routers without affecting the functionality of the network. As more IPv6 routers incorporate these functions, then more IPv64 packets will be processed as IPv6 instead of as IPv4, smoothly migrating the network functionality to IPv6. The resources, and the calendar time, that the aforementioned modification in the procedures require should be balanced against the benefits in transition time brought by incorporating this additional transition mechanism. 10. Acknowledgements This work has used valuable comments received from Tony Hain, Brian E. Carpenter and Svend Moeller Nielsen. A. Azcorra Informational - Expires February 9, 2002 11 INTERNET DRAFT IPv64 Specification September 2, 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. [RFC-2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP",RFC 2481, January 1999. Author's Addresses Arturo Azcorra Universidad Carlos III de Madrid Av. Universidad 30 28911 Leganes (Madrid) SPAIN Email: azcorra@it.uc3m.es 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. A. Azcorra Informational - Expires February 9, 2002 12 INTERNET DRAFT IPv64 Specification September 2, 2001 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. A. Azcorra Informational - Expires February 9, 2002 13