A. Azcorra Internet Draft Univ. Carlos III Document: draft-azcorra-ipv64-01.txt de Madrid Expires: February 9, 2002 August 27, 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 modification that allows IPv6 to be backward compatible with IPv6. An IPv6 packet sent in this way would be undistinguishable from plain IPv4 packets to IPv4- only routers. Therefore, IPv6 routers will process the packet as an IPv6 packet, and at the same time, in case there is an IPv4-only router in the path, it will correctly process and forward the packet. Consequently, it is possible to have native end-to-end IPv6 communication 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. Therefore, IPv6 routers will process the packet as an IPv6 packet, but the destination host will correctly process it as an IPv4 packet. A. Azcorra Informational - Expires February 9, 2002 1 INTERNET DRAFT IPv64 Specification August 27, 2001 Table of Contents 1. Changes from previous version of the draft......................3 2. Introduction....................................................3 3. IPv6 Header Format..............................................4 4. IPv64 Source Address Extension Header...........................8 5. IPv6 Extension Headers in IPv64 packets.........................9 6. IPv4 Options in IPv64 packets...................................9 7. Firewalls and other protocol functions..........................9 8. Sending IPv64 packets to IPv4-only destinations.................9 9. Identification of IPv64 packets at IPv6 routers................11 10. Conclusions...................................................13 A. Azcorra Informational - Expires February 9, 2002 2 INTERNET DRAFT IPv64 Specification August 27, 2001 1. Changes from previous version of the draft Destination address has been relocated so the field is aligned to a 64 bits boundary. Usage of the term "Differentiated Services Field" instead of "Differentiated Services Code Point" for the corresponding sub-field in the IPv64 header. Clarification of the restriction on the usage of IPv6 extension headers and IPv4 options. Introduction of an IPv64 packet that can be sent, and correctly processed, by IPv4-only destination hosts, without any additional software installed in them. 2. Introduction The intention of this document is to provide an improved transition mechanism to facilitate the migration from IPv4 to IPv6. The improved transition mechanism would allow that IPv6 be backward compatible with IPv4. Being backward compatible means that it is possible to send an IPv6 packet "cloning" an IPv4 packet so it 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 in native way, 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. For IPv4 hosts, it is possible to upgrade them with IPv6 functionality by installing an IPv6 packet over IPv4, as currently done with tunneling. 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 capabilities of IPv6, but still it is possible to get the advantages of IPv6 in-transit processing. A. Azcorra Informational - Expires February 9, 2002 3 INTERNET DRAFT IPv64 Specification August 27, 2001 To achieve the aforementioned functionalities it is required to define an IPv6 packet format that allows the "clonation" of an IPv4 packet. This is 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. These concepts allow the different interpretation of a given data item depending on the context. In our case, these concepts will be applied mainly to the interpretation of the content of the IPv6 source address field, and in a lesser extent to other fields. 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. 3. 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 Fld | Total/Payload Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | + + | | + Source Address + | | + + | | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Flow Label (Low 16) | Next Header | Hop Limit | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | + + | | + Destination Address + | | + + | | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1 Version This field contains the 4-bit Internet Protocol version number. Acceptable values for this field are 4 and 6. A. Azcorra Informational - Expires February 9, 2002 4 INTERNET DRAFT IPv64 Specification August 27, 2001 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 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. 3.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. 3.3 Differentiated Services Field The value of this field should be coded as specified in RFC 2474 and RFC 2481. 3.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 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A. Azcorra Informational - Expires February 9, 2002 5 INTERNET DRAFT IPv64 Specification August 27, 2001 The "Flags" Field is divided in three one-bit sub-fields as follows: 16 17 18 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | IPv64 Packet | Do not Fragment | More Fragments | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The values of all the previous 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. 3.4.1 Fragmentation Control Sub-Fields This applies to sub-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 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, in-transit fragmentation is not allowed. The DF bit in the fragmentation sub-field 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 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 will be needed: 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 set to zero. 3.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 an alternative design would be that IPv6 routers decrement both the TTL sub-field and the Hop Limit fields. A. Azcorra Informational - Expires February 9, 2002 6 INTERNET DRAFT IPv64 Specification August 27, 2001 3.4.3 Protocol For an IPv6 capable destination node, the value coded in this field is irrelevant. However, for IPv4 hosts that has been upgraded to IPv6 functionality by installing an IPv6 layer over IPv4, the value coded in the Protocol field MUST NOT be that of IPv6, as done in tunneling, because the payload does not contain a complete IPv6 packet. Therefore, it is needed to define a specific, and currently unused, value (e.g. value 101 decimal, see RFC 1700) to identify incoming IPv64 packets to be correctly processed by the IPv6 layer installed over the IPv4 layer. This 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 specification of this protocol entity remains for further study. 3.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.) 3.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. 3.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. A. Azcorra Informational - Expires February 9, 2002 7 INTERNET DRAFT IPv64 Specification August 27, 2001 3.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. The remaining part of this section applies therefore only to IPv64 packets. 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 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. 3.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. 3.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. 3.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. 4. IPv64 Source Address Extension Header A. Azcorra Informational - Expires February 9, 2002 8 INTERNET DRAFT IPv64 Specification August 27, 2001 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 case it is required under some circumstances. The definition of the said Extension Header is not a subject of this document and is left for further study. 5. 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 header, and with the same structure and semantics. 6. IPv4 Options in IPv64 packets Under the definition of IPv64 in this document, it is not possible to use IPv4 options in IPv64 packets. Ideally, it would be better to allow the usage of IPv4 options. If doing so, the IPv6 Destination Address field would then be located 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, and not using IPv4 options is not considered a big disadvantage, in particular taking into account that it is possible to use IPv6 extension headers. 7. Firewalls and other protocol functions A 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 NAT, ICMP diagnostics, and other functions over IPv64 remains for further study. 8. Sending IPv64 packets to IPv4-only destinations This feature remains for further study. What follows is the current state of the design. A. Azcorra Informational - Expires February 9, 2002 9 INTERNET DRAFT IPv64 Specification August 27, 2001 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), while sending packets to an IPv4-only host. The basic idea is to encode the remaining part of the IPv64 header, above the IPv4 header, as IPv4 options. 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". 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 IPv4 options field, which on some IPv4 routers would imply processing the packet on the slow path. Another disadvantage is that the Flow Label (Low) field is used to encode the IPv4 options, and would therefore not be available for other purposes. 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. 8.1 Flow Label (High) Field This field MUST be set to decimal ten, binary encoded. The reason is that the IPv6 Fields: Flow Label (Low), Next Header, Hop Limit, and Destination Address field will have to be considered as an IPv4 option, for them to be ignored by the destination. 8.2 Flow Label (Low) Field The value of this field is used to resemble the first two octets in the IPv4 options field. Therefore, its value MUST be set to: Type Length +--------+--------+ |10010100|00010100| +--------+--------+ Type: Copied flag: 0 (fragments must not carry the option) A. Azcorra Informational - Expires February 9, 2002 10 INTERNET DRAFT IPv64 Specification August 27, 2001 Option class: 10 (debugging and measurement) Option number: 11111 (31 decimal) Length: 00010100 (20 decimal) Note 1: The selection of the option class could be changed in case the usage of the reserved or control ones reports an advantage (e.g. avoid processing in the slow path). Note 2: The selection of the option number could be changed to any other unassigned one. 8.3 Protocol Sub-field This sub-field MUST carry the protocol identifier of the PDU in the packet payload, instead of a specific value (e.g. 101) to identify IPv64 packets. 8.4 Fragmentation sub-fields In-transit IPv4 fragmentation can not be permitted because it would not copy the remaining 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 in case it is desired to send a payload that implies a datagram size above the path MTU. In this case, source-node IPv4 fragmentation MUST be used, and therefore the values of the fragmentation sub-fields should be coded according to the fragmentation specification of IPv4 in RFC 791. 8.5 IPv6 Extension Headers End-to-end IPv6 extension header 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. An alternative design option is that extension headers could be incorporated to the IPv4 header by including them in the options part of the IPv4 header (increasing the IHL value and options size). It has not been allowed because this approach would suffer from the limitation of the maximum size of the IPv4 header, which is 15 words of 32 bits. 9. Identification of IPv64 packets at IPv6 routers A. Azcorra Informational - Expires February 9, 2002 11 INTERNET DRAFT IPv64 Specification August 27, 2001 When a native 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 first proposal for this function is that the currently unused bit in the IPv4 header (that has been called "IPv64 Packet" sub- 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 implementation 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 may be found to be large, several alternative procedures have been considered. These procedures are described in the following sub-sections. 9.1 Using the reserved IPv4 option number IPv64 packets sent as IPv4 compatible packets would have the specific option number (e.g. 31) 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 not being able to use the flow-label field. Alternative b) is feasible (see the next 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. 9.2 Protocol Sub-field The content of the Protocol sub-field could be used to detect IPv64 packets sent in regular format (i.e. not in IPv4-compatible format). When a packet has the reserved value (e.g. 101) in this field, then it is an IPv64 packet. 9.3 DSCP Field A. Azcorra Informational - Expires February 9, 2002 12 INTERNET DRAFT IPv64 Specification August 27, 2001 The six-bit DSCP 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. 9.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 as specified in RFC 3022. 10. Conclusions The modification of the location of IPv6 fields, plus the complementary transition mechanisms described in this document, would imply a change in the IPv6 implementations. The resources, and the calendar time, that this change would require should be balanced against the benefits in transition time brought by having an IPv6 protocol backward compatible with IPv4, as described above. A. Azcorra Informational - Expires February 9, 2002 13 INTERNET DRAFT IPv64 Specification August 27, 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 14 INTERNET DRAFT IPv64 Specification August 27, 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 15