| Network Working Group | P.R. Tattam |
| Internet-Draft | Tattam Software Enterprises Pty Ltd, Hobart, Australia |
| Intended status: Experimental Protocol | January 2012 |
| Expires: July 02, 2012 |
Stateless IPv6 delivery within IPv4 (V6 via V4)
draft-v6-via-v4-00
This document describes a method for transmitting IPv6 packets directly to and from IPv4 hosts via the IPv4 network in a stateless manner using an IPv4 header option and transponders. Additionally described is a mechanism to automatically locate IPv6 network transponders via well known IPv4 and IPv6 network prefixes.
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 02, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Since its acceptance as new standard, deployment of IPv6 [RFC2460] has been somewhat slower than anticipated. The original transition strategy was to deploy IPv6 alongside IPv4 in the expectation that the IPv6 network would grow to such an extent that it would supplant the aging IPv4 network. This, however, has not been the case, and in early 2011 top level IPv4 address allocations in at least one regional registry were exhausted.
One of the possible reasons for the slow uptake of IPv6 is that the current IPv6 protocol is not backwardly compatible with widely deployed IPv4 protocol. This in turn has led to a reluctance by network infrastructure suppliers to deploy IPv6 natively. Another significant factor has been that in recent years much end-user customer link level infrastructure has only supported IPv4 network services (layer 2 services, customer DSL routers etc). To supply both IPv4 and IPv6 service typically requires having to roll out a duplicate network topology, both at the transport layer and at the link level layer making, which is not economically viable within an industry highly sensitive to delivery costs.
This document outlines a proposal to deliver IPv6 network access over IPv4 only infrastructure without the use of tunnels. It is divided into two parts, the first being a header extension to provide IPv6 addressing for an IPv4 packet, and the second an addressing proposal for default IPv4 to IPv6 traffic.
Ultimately such a protocol enhancement to IPv4 could logically join the IPv4 and IPv6 networks together allowing the IPv6 network to grow without the risk of being isolated from the IPv4 network despite the exhaustion of IPv4 address space.
Let us suppose that we want an IPv4 only host to communicate with an IPv6 only host directly. We will divide this problem into two tasks.
The first task is for us to send an IPv4 packet to an IPv6 host. For the packet to be routable to the IPv6 host, it must contain an IPv6 address destination, but the IPv4 packet only has space for an IPv4 address of 32 bits, so it is proposed that we either extend the IPv4 address by including the remaining 96 bits to make an IPv6 address of 128 bits, or that we simply include the full IPv6 address as an IPv6 address extension. Operational experience has shown that the latter is preferable in that it provides us the freedom to choose an arbitrary IPv4 address as a "helper" address to route the packet to its IPv6 destination (typically a V4 to V6 transponder). To do this, it is proposed that the following IPv4 header option be approved by IANA. This allows a data packet to transit the IPv4 network without the use of tunnels in a stateless manner. Once the packet reaches the transponder, it is reformatted and retransmitted into the IPv6 network where it will reach its ultimate destination.
An IPv6 via IPv4 packet is defined as standard IPv4 packet with the inclusion of a single IPv4 header Option (IPv6 address extension). The layout of this IPv4 header option is as follows.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = nnn | Length = 20 | Flags |I|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 Header Option (IPv6 Address Extension) has a value which as yet unassigned.
The IPv4 Header Option (IPv6 Address Extension) has a fixed length of 20 octets
IPv4 Header Option (IPv6 Address Extension) has a 16 bit flags field. Currently the only defined bits are the D (Direction) bit and the I (ignore checksum) . All other values are reserved.
The IPv6 Address is a replacement for the IPv4 Destination Address
The IPv6 Address is a replacement for the IPv4 Source Address
Relevant payload checksums SHOULD BE modified
Relevant payload checksums SHOULD NOT be modified.
The full IPv6 address that should replace the source or destination IPv4 address. If D = 0, this represents the destination IPv6 address. If D = 1, this represents the source IPv6 address.
A typical V6 via V4 packet header would look like the following.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER=4 |IHL=10 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = nnn | Length = 20 | |I|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | | ...... |
On receipt of an IPv6 via IPv4 packet a suitable transponder can convert the packet in situ to an IPv6 packet using the following rules. Two cases apply, the first being when a packet is destined to an IPv6 host (D = 0), for which the following rules apply.
Note that if the IPv6 packet is reconstructed in situ, the rules need to be applied in the above order so as not to overwrite unprocessed information. In particular, the IPv6 flow label and IPv4 packet length overlap. Also note that in step 10, the IPv6 destination will be in the correct place so it need not be copied. Finally it can be observed that the IPv6 source address will be recognizable as coming from the IPv4 network by checking its 96 bit (or 64/32 bit) prefix. Suitable choice of V6_VIA_V4_PREFIX will be discussed later. Also consideration must be made towards modifying payload checksums if necessary.
The packet should end up looking like a normal IPv6 packet as follows.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER=6 | Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | | |
The other case is where a packet is received by an IPv4 host which is the ultimate destination for traffic from a native IPv6 host. In this case the direction bit will be set (D=1) indicating that the address extension is for the IPv6 source. The following rules apply to convert the packet from the IPv4 form to the eventual IPv6 form for processing directly within the originating hybrid IPv4/IPv6 host or for retransmission within a local IPv6 LAN.
This process is the converse of sending a packet from IPv4 to IPv6 and involves constructing an IPv4 header based on the IPv6 header. There are two possibilities here, the first case is when a packet originates from a native IPv6 host (i.e. a machine on the live IPv6 network) and the second case when a packet originates from an IPv6 host within the IPv4 network. This can be determined by a transponder by examining the IPv6 source address. A packet originating from inside the IPv4 network MUST use an IPv6 address constructed from the special V6_VIA_V4_PREFIX concatenated with it's native IPv4 address.
In the case that the IPv6 packet originates from an IPv6 within the IPv6 network, the following rules apply
In the case that the IPv6 packet originates from an IPv6 host within the IPv4 network, the following rules apply
Now the typical length of an IPv4 header is 20 bytes, whilst that of an IPv6 header is 40 bytes. The size of the IPv6 address extension has been chosen such that the size of an V6 via V4 extended packet is that same size as its equivalent IPv6 packet. Operational experience using tunnels has shown that packet size changes during transit cause an MTU impedance mismatch. If the IPv6 address extension is the only IPv4 header option, then translation to an IPv6 packet can be done in situ. Additionally, for a packet destined to an IPv6 host, the IPv6 destination address will be in the correct place.
Certain IP transport protocols such as TCP and UDP contain a payload checksum which includes the address end-points of the packet. Initially, the packet originator SHOULD calculate the checksum using the ultimate IPv6 source and destinations address. The possibility of IPv4 NATs in the packet path complicates matters somewhat since the traffic is actually live IPv4 traffic, not tunnelled, and a NAT will modify payload checksums, possibly by updating the existing checksum by applying a delta, or by recalculating the checksum. To handle this situation, any V6 via V4 packets within the IPv4 network should be maintained internally consistent. This involves firstly modifying the payload checksum upon entry and exit from the IPv4 network. Initial operational experience has shown that this can be achieved in the following manner.
To convert a V4viaV6 payload checksum
To convert a V6 payload checksum
There are some minor optimizations that can be taken in the process. For example, the V6_VIA_V4_PREFIX will be constant meaning a constant value can be applied for that component of the translation (indeed if the prefix were 0, no adjustment would be required).
It can also be determined by a discovery process whether checksum modification is actually required and if not, the I (ignore checksum) bit can be set in the flags of the header option to disable this feature. This feature is still an area for future research. This does not apply to the IPv4 header checksum which must always be valid.
The payload checksums for ICMP, ICMPv6, TCP and UDP packets are in a fixed location in the payload, and these are currently the only protocols for which these actions will be defined.
It is suggested that ICMPv6 traffic be allowed to traverse the IPv4 network when IPv6 via IPv4 packets are used. This should allow ICMPv6 messages to pass between end points since we are ultimately only interested in IPv6 communication. However there may be times where intervening routers on the IPv4 network may respond with ICMP messages. Any host participating in this process should be prepared to receive ICMP packets if they have originated from the IPv4 network. More operational experience will be required to determine the nature of such traffic. Translation of ICMP messages to ICMPv6 and vice versa is the subject of further research at this stage.
For an IPv4 packet to be able to be suitably transmitted, the following restrictions SHOULD be adhered to.
The HELPER_ADDRESS() function is a special function which takes the IPv6 destination address (a native IPv6 address) and converts it into an IPv4 address for transit out of the IPv4 network.
Operational testing has shown that there is some flexibility in the choice of HELPER_ADDRESS() which is used to translate IPv6 packets into IPv6 via IPv4 packets. The simplest function would be to use a fixed address, which in real terms would be the IP address of an IPv6 transponder visible from IPv4 hosts able to participate in the IPv6 via IPv4 protocol.
Discussed later in this document is a proposal for a version of the HELPER_FUNCTION() which can be used in a global manner.
For this mechanism to operate, IPv6 packets destined for the IPv4 network need to be identified. It is proposed that a well known IPv6 address allocation of at least /32 be allocated for this purpose. It is not known at this stage if this mechanism can coexist with similar prefix allocations for IPv6 NAT mechanisms. For efficiency with typical network infrastructure, it is preferable that it be unique in the IPv6 address space for the top 32 bits of the prefix (i.e. a /32 allocation).
For this protocol to function, it needs to differentiate traffic at the network layer. As a minimum in the IPv6 world, IPv4 destined traffic needs to be identifiable with a known prefix, and in the IPv4 world an IPv4 address or network needs to be visible for which transponders exist which bridge the IPv4 and IPv6 worlds. Also any IPv6 capable host which is operating in the IPv4 world should have a local address constructed from its IPv4 address and the V6_VIA_V4_PREFIX.
One of the significant obstacles to continued growth of the IPv6 network has been that of the address depletion happening faster than was anticipated. This has created two disjoint networks. New address allocations are made from the IPv6 network but these have limited value since only IPv6 network hosts can see them. Conversely, IPv4 address allocations are now at a premium due to scarcity. It would be prudent if there were a standard mechanism by which existing IPv4 hosts could automatically see IPv6 hosts and vice versa. This is termed as the backward compatibility problem.
Whilst this proposal can't fully deliver seamless connectivity between the two networks, it can at least go a long way towards that in that any host armed with the IPv6 via IPv4 protocol could potentially achieve full IPv6 connectivity provided the IPv6 network were accessible from the IPv4 network via a well known IPv6 via IPv4 prefix. The local network need not be IPv6 connected or implement IPv6 via IPv4 transponders so long as it can direct any such traffic to a well known IPv4 prefix for such traffic. Given the extreme need for traffic to be able to automatically pass between the two networks in the long term, it is conceivable that a special allocation be made for such traffic. This proposal suggests a possible standard addressing scheme for IPv6 via IPv4 traffic which obviates the need for end user configuration or transponder discovery.
One possible HELPER_ADDRESS() function might be the function
HELPER_ADDRESS(v6_address) = ((v6_address << 3) >> (V6_VIA_V4_NETWORK_PREFIXLEN + 96) ) + V6_VIA_V4_NETWORK
i.e. After removing the top 3 bits, take N bits from the routable part of the IPv6 address and assign them to the subnet address part of the routable IPv4 prefix.
Such a prefix could be any allocation from the IPv4 network from /24 up to /8, possibly even up to /4. One possible candidate might be the reserved sections of the IPv4 network such as 224.0.0.0/4, 255.0.0.0/8 or 255.255.0.0/16. The degenerate case would be a single well known address (/32) which could be used to direct traffic to the IPv6 network.
For the HELPER_ADDRESS() function to operate on global basis, it would be advantageous to have an IPv4 address allocation of a suitable size that would allow for IPv6 via IPv4 traffic to be routable in a useful manner. This would effectively be an address range which is a window to the IPv6 world from the IPv4 world.
Let us consider a round trip of an IPv4 host (A) sending a packet to IPv6 host (B). IPv4 host A has only local IPv4 traffic capability and IPv6 host B has only local IPv6 capability. We also assume there is an IPv6 via IPv4 transponder (X) which is accessible from both A and B, i.e. X has both native IPv4 and native IPv6 access. Initially we will also assume that whilst host A has only IPv4 connectivity, it is IPv6 capable, and also understands the IPv6 via IPv4 protocol.
Host A will have an IPv4 address and also the pseudo IPv6 address constructed from the well known V6_VIA_V4_PREFIX address space.
Transponder X be will transparent to host B, but we assume that any traffic for the V6_VIA_V4_PREFIX address space will be directed to it.
Traffic flow from A to B is as follows.
Traffic flow from B to A is as follows.
Our network round trip is now complete.
There are some variants to this process which can be applied.
Suppose that we have another host C which is not IPv6 aware at all. In this case, it would need assistance to reach the IPv6 network. In this case A can act as an agent to make the IPv6 network visible to C. It would need to provide a pool of IPv4 to IPv6 translation pairs which it would need to maintain in a stateful manner. It would also need to supply pseudo IPv4 DNS A records such that C would be able to discover the pseudo IPv4 address of B. The behaviour of A in this case would be similar to traditional IPv6 NAT operation.
An additional variant of the basic scenario is that A can also act as an agent for other IPv6 enabled machines which have no IPv6 connectivity but are able to reach A via localized IPv6. In this scenario, each IPv6 machine should be using a local IPv6 address with the V6_VIA_V4_PREFIX. When A is acting as an agent for such traffic, it would follow similar steps to the above example, but replacing the v4.src address in the V6 via V4 packet by the originating IPv6 machine.
Another possible variant to this scenario is when X is not identified as a specific machine, but is rather the destination route for a known IPv4 network prefix using the extended HELPER_ADDRESS() function described earlier in the document. In this manner, the transponder functions could be distributed based upon the IPv6 prefix of destination from the IPv4 side.
From the IPv6 network side, transmitting back to the IPv4 network could be either an all-or-nothing style of routing or some coarse grained routing could be applied to the component IPv4 destination address. However in order to conform with the strong aggregation of IPv6, such behaviour should be deprecated.
Theoretically, all IPv4 machines should be reachable from the IPv6 network and vice versa as long as any such machines are IPv6 via IPv4 capable and that there are transponders at transition points between the two networks.
It should also be noted that the transponder component of this protocol is stateless, and that there is no MTU change for transition for packets from IPv4 to IPv6. The only significantly identifiable transponder cost would be the cost of rearranging the packet and recalculation of payload checksums if required. IPv4 header checksum recalculation is only required for the return path from an IPv6 host to an IPv4 host.
This document requests the following from IANA
Note to RFC Editor: this section may be removed on publication as an RFC.
IPv6-IPv4 transponders will have a similar function to routers in that they will be handling high volumes of traffic. While the stateless mechanism described should have a trivially small amount of computing to rebuild the packet which comprises of reordering the header and possibly recomputing check sums, it may still be subject to denial of service issues.
It is conceivable that transponders may become overloaded from the receipt of traffic over which it has no control. This is however a similar scenario to that of core routers having to deal with transit traffic, and similar measures should apply.
Any host which implements this protocol extension in a hybrid IPv4/IPv6 stack should take care that translated packets are managed correctly to prevent address space back doors.
Operational experience has indicated that some implementations and firewalls may reject or flag packets containing the extended IPv4 header options. In particular it was noticed that one TCP/IP stack sent ICMP parameter problem messages in response to valid IPv4 header options. There needs to be negotiation with TCP/IP stack and firewall vendors to resolve such issues.
The author wishes to thank internet pioneer Vint Cerf for his insightful thoughts during early drafts of this proposal.
The author also wishes to thank Medical-Objects Pty Ltd for the continuing use of their IPv6 enabled infrastructure in the development of this proposal.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2460] | Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. |