Internet DRAFT - draft-v6-via-v4
draft-v6-via-v4
Network Working Group P. Tattam
Internet-Draft Tattam Software Enterprises Pty
Intended status: Experimental Ltd, Hobart, Australia
Expires: July 18, 2012 January 15, 2012
Stateless IPv6 delivery within IPv4 (V6 via V4)
draft-v6-via-v4-00
Abstract
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.
Requirements Language
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].
Status of this Memo
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 18, 2012.
Copyright Notice
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
Tattam Expires July 18, 2012 [Page 1]
Internet-Draft V6viaV4 January 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transmission of IPv6 payload via IPv4 . . . . . . . . . . . . 3
2.1. Sending a packet from IPv4 to IPv6 . . . . . . . . . . . . 3
2.1.1. IPv4 Header Option (IPv6 Address Extension) . . . . . 4
2.1.2. Code (to be allocated) . . . . . . . . . . . . . . . . 4
2.1.3. Length . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5. Translation of IPv6 via IPv4 packet to an IPv6
packet . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Sending a packet from IPv6 to IPv4 . . . . . . . . . . . . 8
2.3. Optimal Alignment of IPv4 header . . . . . . . . . . . . . 10
2.4. Handling Payload Checksums . . . . . . . . . . . . . . . . 10
2.5. Handling ICMP and ICMPv6 traffic . . . . . . . . . . . . . 12
2.6. Additional IPv4 packet considerations . . . . . . . . . . 12
2.7. Definition of HELPER_ADDRESS() . . . . . . . . . . . . . . 12
2.8. Definition of V6_VIA_V4_PREFIX (IPv6) . . . . . . . . . . 13
2.9. Local Operation of Protocol . . . . . . . . . . . . . . . 13
3. Global Network Allocation for IPv6 via IPv4 traffic . . . . . 13
3.1. HELPER_ADDRESS() function for global IPv6 via IPv4
access . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Definition of V6_VIA_V4_NETWORK (IPv4) . . . . . . . . . . 14
4. Example of IPv6 via IPv4 traffic . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tattam Expires July 18, 2012 [Page 2]
Internet-Draft V6viaV4 January 2012
1. Introduction
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.
2. Transmission of IPv6 payload via IPv4
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.
2.1. Sending a packet from IPv4 to IPv6
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
Tattam Expires July 18, 2012 [Page 3]
Internet-Draft V6viaV4 January 2012
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.
2.1.1. IPv4 Header Option (IPv6 Address Extension)
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Header Option (IPv6 Address Extension)
2.1.2. Code (to be allocated)
The IPv4 Header Option (IPv6 Address Extension) has a value which as
yet unassigned.
2.1.3. Length
The IPv4 Header Option (IPv6 Address Extension) has a fixed length of
20 octets
2.1.4. Flags
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.
Tattam Expires July 18, 2012 [Page 4]
Internet-Draft V6viaV4 January 2012
2.1.4.1. D (Direction) bit = 0
The IPv6 Address is a replacement for the IPv4 Destination Address
2.1.4.2. D (Direction) bit = 1
The IPv6 Address is a replacement for the IPv4 Source Address
2.1.4.3. I (ignore checksum) bit = 0
Relevant payload checksums SHOULD BE modified
2.1.4.4. I (ignore checksum) bit = 1
Relevant payload checksums SHOULD NOT be modified.
2.1.4.5. IPv6 Address
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.
2.1.5. Translation of IPv6 via IPv4 packet to an IPv6 packet
A typical V6 via V4 packet header would look like the following.
Tattam Expires July 18, 2012 [Page 5]
Internet-Draft V6viaV4 January 2012
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 |
| ...... |
IPv6 via IPv4 packet format
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.
1. IPv6.Version = 6
2. IPv6.traffic_class = 0
3. IPv6.flow_label[16:19] = 0
4. IPv6.payload_len = IPv4.len - (IPv4.header_len*4)
5. IPv6.flow_label[0:15] = 0
6. IPv6.next_header = IPv4.protocol
7. IPv6.hop_limit = IPv4.ttl
Tattam Expires July 18, 2012 [Page 6]
Internet-Draft V6viaV4 January 2012
8. subtract IPv4 addresses from payload checksum if necessary
9. IPv6.src_addr = IPv4.src_addr + V6_VIA_V4_PREFIX
10. /* IPv6.dst_addr = IPV4.option_v6_address_extension.ipv6_address
*/
11. add IPv6 addresses to payload checksum if necessary
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 |
| |
Tattam Expires July 18, 2012 [Page 7]
Internet-Draft V6viaV4 January 2012
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.
1. IPv6.Version = 6
2. IPv6.traffic_class = 0
3. IPv6.flow_label[16:19] = 0
4. IPv6.payload_len = IPv4.len - (IPv4.header_len*4)
5. IPv6.flow_label[0:15] = 0
6. IPv6.next_header = IPv4.protocol
7. IPv6.hop_limit = IPv4.ttl
8. subtract IPv4 addresses from payload checksum if necessary
9. IPv6.src_addr = IPV4.option_v6_address_extension.ipv6_address
10. IPv6.dst_addr = IPv4.src_addr + V6_VIA_V4_PREFIX
11. add IPv6 addresses to payload checksum if necessary
2.2. Sending a packet from IPv6 to IPv4
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
Tattam Expires July 18, 2012 [Page 8]
Internet-Draft V6viaV4 January 2012
1. subtract IPv6 addresses from payload checksum if necessary
2. temp_addr = IPv6.src_addr
3. IPv4.dst_addr = IPv6.dst_addr[0:31]
4. IPv4.src_addr = HELPER_ADDRESS(IPv6.src_addr)
5. IPv4.option_v6_address_extension.type = nnn (to be assigned)
6. IPv4.option_v6_address_extension.len = 20
7. IPV4.option_v6_address_extension.D = 1
8. IPv4.option_v6_address_extension.IPv6_address = temp_addr
9. IPv4.version = 4
10. IPv4.header_len = 10 /* (20 + 20)/4 */
11. IPv4.tos = 0
12. IPv4.len = IPv6.payload_len + (IPv4.header_len *4)
13. IPv4.ttl = IPv6.hop_limit
14. IPv4.id = allocate_new_id
15. IPv4.protocol = IPv6.next_header
16. IPv4.fragment = 0
17. IPv4.dont_fragment = 1
18. IPv4.header_checksum = recalculate header checksum
19. add IPv4 addresses to payload checksum if necessary
In the case that the IPv6 packet originates from an IPv6 host within
the IPv4 network, the following rules apply
1. subtract IPv6 addresses from payload checksum if necessary
2. IPv4.dst_addr = HELPER_ADDRESS(IPv6.dst_addr)
3. IPv4.src_addr = IPv6.src_addr[0:31]
Tattam Expires July 18, 2012 [Page 9]
Internet-Draft V6viaV4 January 2012
4. IPv4.option_v6_address_extension.type = nnn (to be assigned)
5. IPv4.option_v6_address_extension.len = 20
6. IPv4.option_v6_address_extension.D = 0
7. /* IPv4.option_v6_address_extension.IPv6_address =
IPv6.dst_address */
8. IPv4.version = 4
9. IPv4.header_len = 10 /* (20 + 20)/4 */
10. IPv4.tos = 0
11. IPv4.len = IPv6.payload_len + (IPv4.header_len *4)
12. IPv4.ttl = IPv6.hop_limit
13. IPv4.id = allocate_new_id
14. IPv4.protocol = IPv6.next_header
15. IPv4.fragment = 0
16. IPv4.dont_fragment = 1
17. IPv4.header_checksum = recalculate header checksum
18. add IPv4 addresses to payload checksum if necessary
2.3. Optimal Alignment of IPv4 header
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.
2.4. Handling Payload Checksums
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
Tattam Expires July 18, 2012 [Page 10]
Internet-Draft V6viaV4 January 2012
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
1. identify whether the packet needs payload checksum modification
2. if so, proceed further, otherwise no further action is required.
3. remove the IPv4 source and destination addresses from the
checksum using ones complement arithmetic
4. include the updated IPv6 source and destination address in the
checksum using ones complement arithmetic
To convert a V6 payload checksum
1. identify whether the packet needs payload checksum modification
2. if so, proceed further, otherwise no further action is required.
3. remove the IPv6 source and destination addresses from the
checksum using ones complement arithmetic
4. include the updated IPv4 source and destination address in the
checksum using ones complement arithmetic
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
Tattam Expires July 18, 2012 [Page 11]
Internet-Draft V6viaV4 January 2012
fixed location in the payload, and these are currently the only
protocols for which these actions will be defined.
2.5. Handling ICMP and ICMPv6 traffic
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.
2.6. Additional IPv4 packet considerations
For an IPv4 packet to be able to be suitably transmitted, the
following restrictions SHOULD be adhered to.
o The IPv4 packet SHOULD only contain a single IPv4 header option
(IPv6 address extension).
o The IPv4 packet MUST have the Don't Fragment bit set (DF=1) , and
the Fragment Offset MUST be zero.
o The IPv4 header field Type Of Service (TOS) is ignored on
conversion to IPv6 and set to zero or default value on conversion
from IPv6.
o The IPv4 header field Identification (ID) is ignored on conversion
to IPv6 and is set to a suitable ID on conversion from IPv6
2.7. Definition of HELPER_ADDRESS()
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
Tattam Expires July 18, 2012 [Page 12]
Internet-Draft V6viaV4 January 2012
HELPER_FUNCTION() which can be used in a global manner.
2.8. Definition of V6_VIA_V4_PREFIX (IPv6)
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).
2.9. Local Operation of Protocol
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.
3. Global Network Allocation for IPv6 via IPv4 traffic
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
Tattam Expires July 18, 2012 [Page 13]
Internet-Draft V6viaV4 January 2012
addressing scheme for IPv6 via IPv4 traffic which obviates the need
for end user configuration or transponder discovery.
3.1. HELPER_ADDRESS() function for global IPv6 via IPv4 access
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.
3.2. Definition of V6_VIA_V4_NETWORK (IPv4)
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.
4. Example of IPv6 via IPv4 traffic
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.
Tattam Expires July 18, 2012 [Page 14]
Internet-Draft V6viaV4 January 2012
Traffic flow from A to B is as follows.
o A requests internally that an IPv6 packet to be sent to B using
the IPv6 addresses (v6.src=A.v6_address, v6.dst=B.v6_address)
o A then internally translates this packet to an IPv6 via IPv4
packet using the address tuple (v4.src=A.v4_address,
v4.dst=X.v4_address, v4.opt_hdr_v6_extension.v6_addr=B.v6_address,
v4.opt_hdr_v6_extension.D=0)
o A then transmits this packet to X on the IPv4 network.
o X receives the packet and retrieves B.v6_address directly from
v4.opt_hdr_v6_extension.v6_addr, and deduces A.v6_address from
v4.src
o X converts it to an IPv6 packet with the address tuple
(v6.src=A.v6_address, v6.dst=B.v6_address)
o X transmits the packet to B on the IPv6 network.
o B receives the packet and processes it as a normal IPv6 packet.
Traffic flow from B to A is as follows.
o B requests that an IPv6 packet be sent to A using the address
tuple (v6.src=B.v6_address, v6.dst=A.v6_address)
o B transmits packet to IPv6 network.
o IPv6 network routes packet to X as a result of the prefix of
v6.dst being equal to V6_VIA_V4_PREFIX.
o X receives the IPv6 packet and determines that it should be
forwarded to A.v4_address. It extracts the IPv4 destination
address from the lower 32 bits of the IPv6 destination address.
o X constructs an IPv6 via IPv4 packet in situ with the address
tuple (v4.src=X.v4_address, v4.dst=A.v4_address,
v4.opt_hdr_v6_extension.v6_addr=B.v6_address,
v4.opt_hdr_v6_extension.D=1)
o X then retransmits the packet on the IPv4 network to A
o A receives the IPv6 via IPv4 packet and reconstructs the original
IPv6 packet with the address tuple (v6.src=B.v6_address,
v6.dst=A.v6_address).
Tattam Expires July 18, 2012 [Page 15]
Internet-Draft V6viaV4 January 2012
o A processes the packet as an IPv6 packet.
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
Tattam Expires July 18, 2012 [Page 16]
Internet-Draft V6viaV4 January 2012
to an IPv4 host.
5. IANA Considerations
This document requests the following from IANA
1. A number assignment for the IPv4 header option
IPV6_ADDRESS_EXTENSION
2. A global IPv6 address /32 allocation (V6_VIA_V4_PREFIX) to
identify traffic destined for the IPv4 network from the IPv6
network. An allocation which simplifies or obviates the need to
V4-V6 address checksum recalculation would be desirable.
3. A global IPv4 address in the range /24 up to /8 allocation
(V6_VIA_V4_NETWORK) to identify traffic destined for the IPv6
network from the IPv4 network.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
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.
Tattam Expires July 18, 2012 [Page 17]
Internet-Draft V6viaV4 January 2012
7. Acknowledgements
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.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Author's Address
Peter Tattam
Tattam Software Enterprises Pty Ltd, Hobart, Australia
Tattam Expires July 18, 2012 [Page 18]
