4via6 Stateless Translation
draft-murakami-softwire-4v6-translation-00

Abstract

This document specify 4via6, a solution for IPv4 connectivity across IPv6 network utilizes 4rd algorithmic address mapping rule as a series of stateless IPv4 over IPv6 migration solutions. 4via6 employ stateless address translation techniques. It is useful for operators who want to provide IPv4 connectivity across restricted bandwidth IPv6 network with stateless operation.

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 January 05, 2012.

Copyright Notice

Copyright (c) 2011 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.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Terminology
• 4. 4via6 Translation Framework
• 5. Stateless Translation Algorithm
• 6. Behavior of 4via6 Stateless Translation
• 6.1. Behavior on 4via6 CE
• 6.2. Behavior on 4via6 BR
• 7. Path MTU and Fragmentation Consideration
• 8. Comparison with 4rd
• 9. Security Considerations
• 10. IANA Consideration
• 11. Acknowledgements
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Authors' Addresses

1. Introduction

4via6 is a solution utilizes the same algorithmic address mapping rule between IPv4 addresses and IPv6 addresses defined in 4rd [I-D.murakami-softwire-4rd]. 4via6 employ stateless address translation techniques well specified in [RFC6145] with the mapping rule in order to communicate IPv4 islands across IPv6 network, instead of IPv6 encapsulation mechanism in 4rd. Address mapping rule defined in [RFC6052] is also employed to preserve correspondant address of outside 4via6 domain.

Since additional IP header is required and the size of the packet is increasing in encapsulation solutions, limited bandwidth resource in a network would be consumed by un-negligible overhead. It is undesirable in that has that limitation like wireless network. 4via6 is useful for operators who want to provide IPv4 connectivity across restricted bandwidth IPv6 network with stateless operation described in [I-D.operators-softwire-stateless-4v6-motivation].

2. 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].

3. Terminology

4via6 domain (Domain):

A set of 4via6 CEs and BRs connected to the same virtual link. A service provider may deploy 4via6 with a single 4via6 domain, or may utilize multiple 4via6 domains. Each domain requires a separate 4via6 prefix.

4via6 Border Relay (BR):

A 4via6-enabled router managed by the service provider at the edge of a 4via6 domain. A Border Relay router has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network. A 4via6 BR may also be referred to simply as a "BR" within the context of 4via6.

4via6 Customer Edge (CE):

A device functioning as a Customer Edge router in a 4via6 deployment. In a residential broadband deployment, this type of device is sometimes referred to as a "Residential Gateway" (RG) or "Customer Premises Equipment" (CPE). A typical 4via6 CE adopting 4rd rules will serve a residential site with one WAN side interface, one or more LAN side interfaces. A 4via6 CE may also be referred to simply as a "CE" within the context of 4via6.

Shared IPv4 address:

An IPv4 address that is shared among multiple nodes. Each node has a separate part of the transport layer port space.

4. 4via6 Translation Framework

Figure 1 depicts the overall architecture with IPv4 users networks connected through routed IPv6 networks. Therein, IPv4 users are connected to IPv6 network via CPE with 4via6 translation modules.

>
    Private IPv4
   |  Network
   |
O-------------------O
|        CPE        |
| +-------+-------+ |
| | NAT44 | 4via6 | |
| |       |  CE   | |\
| +-------+-------+ | \    ,-------.                     /------.
|                   |  \,-'         `-.               ,-/       `-.
O-------------------O /   Routed      \  O---------O /   Public    \
                     /    IPv6         \ |         |/     IPv4      \
                    |    Network       --+  4via6  +-   Network     |
                     \                /  |   BR    |\               /
                      \              /   O---------O \             /
                       ".         ,-'                  `-.       ,-'
                         `-------'                        `------'
        

4via6 CE has two functionalities. The first is to generate an IPv4 address or an shared IPv4 address and port-set. The second is to translate an IPv4 packet from/to an IPv6 packet across IPv6 network.

When an unique IPv6 prefix is assigned to each CPE from SP's network, 4via6 CE in the CPE generates IPv4 address or shared IPv4 address and port-set with 4rd address mapping rule defined in [I-D.murakami-softwire-4rd].

The address mapping rule is also used in 4via6 CE to forward the packets. When 4via6 CE sends a packet to BR, the source address is translated from IPv4 to IPv6 address with 4rd mapping rule and the destination address is translated from IPv4 to IPv6 address with [RFC6052]. In the case of sending the packet to another CE, the destination address is translated with 4rd address mapping rule.

NAT44 must be implemented in 4via6 CPE with the behavior conforming to the best current practice documented in [RFC4787], [RFC5508] and [RFC5382]. The NAT44 must translate the port number into the port-set generated in a given 4via6 CE.

At a BR side, when the BR sends a packet to a CE, the source address is translated from IPv4 to IPv6 address with [RFC6052] and the destination address is translated from IPv4 to IPv6 with 4rd mapping rule.

5. Stateless Translation Algorithm

The stateless translation between IPv6 and IPv4 must conform to [RFC6145]. The address mapping rule must be based on [I-D.murakami-softwire-4rd] and [RFC6052].

In 4via6 stateless translation, the only difference is the forwarding mechanism across IPv6 network infrastructure. The automatic tunneling mechanism such as IPv4-in-IPv6 is used in [I-D.murakami-softwire-4rd]. Instead, for the outband direction, the source address is translated with 4rd mapping rule and the destination address is translated with [RFC6052]. From the inbound direction, the source address is translated with [RFC6052] and the destination address is translated with 4rd mapping rule. For the direct communication among CEs, both source address and destination address are translated with only 4rd mapping rule.

6. Behavior of 4via6 Stateless Translation

6.1. Behavior on 4via6 CE

A 4via6 CE that receives IPv4 packets from CE LAN side checks the validity of its source and destination address. It also checks that the packet size is acceptable. If yes, NAT44 changes the IPv4 source address and the source port to its generated global IPv4 address and the port within the generated port-range. After that, 4via6 CE performs the translation of IPv4 source address and IPv4 destination address. The IPv4 source address is changed to the IPv6 address that is assigned to the 4via6 CE. The IPv4 destination address is translated based on [RFC6052]. And the IPv4 header is replaced to the IPv6 header that is generated from the IPv4 header based on [RFC6145].

The 4via6 CE that receives IPv6 packet from CE WAN side checks the validity of its source and destination address. It also checks that the packet size is acceptable. If yes, it translates the IPv6 source and the IPv6 destination address in the received packets. The IPv6 destination address is changed to the IPv4 address that is generated in the 4via6 CE based on [I-D.murakami-softwire-4rd]. The IPv6 source address is translated based on [RFC6052]. After that, the IPv6 header is replaced to the IPv4 header that is generated from the IPv6 header based on [RFC6145].

6.2. Behavior on 4via6 BR

A 4rd BR that receives IPv4 packets from the outside IPv4 network checks the validity of its source and destination address. It also checks that the packet size is acceptable. If yes, it generates the IPv6 destination address from the IPv4 destination address based on [I-D.murakami-softwire-4rd] and translates the IPv4 source address to the IPv6 source address based on [RFC6052]. As the result, the IPv4 header is replaced to the IPv6 header based on [RFC6145].

The 4rd BR that receives IPv6 packets from IPv6 network infrastructure checks the validity of its source and destination address. It also checks that the packet size is accpetable. If yes, it generates the IPv4 source address from the IPv6 source address based on [I-D.murakami-softwire-4rd] and translates the IPv6 destination address to the IPv4 destination address based on [RFC6052]. As the result, the IPv6 header is replaced to the IPv4 header based on [RFC6145].

7. Path MTU and Fragmentation Consideration

Basically, Path MTU and Fragmentation must confirm to Section 1.4 of [RFC6145].

In 4via6 stateless transition, a 4via6 BR and a 4via6 CE replace an IPv6 header to an IPv4 header in a received IPv6 packet upon forwarding the packet to a native IPv4 interface. If the size of the IPv4 packet might exceed to the IPv4 MTU on the native IPv4 interface, the 4via6 BR and the 4via6 CE might fragment the packet. In order for the receiver to reassemble the fragmented packet correctly, the 4via6 BR and the 4via6 CE must assign an unique value to a datagram ID in IPv4 header upon forwarding the packet to the native IPv4 interface.

8. Comparison with 4rd

Differing from encapsulation model, translation approach doesn't need to know BR IPv6 address. Instead of that, a IPv6 mapping prefix should be delivered to 4via6 CPEs or 4via6 hosts for generating IPv6 address by catenating IPv4 destination address with IPv6 mapping prefix. Such IPv6 mapping prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators.

9. Security Considerations

The security consideration is same as [I-D.murakami-softwire-4rd].

10. IANA Consideration

This document has no IANA actions.

11. Acknowledgements

12. References

12.1. Normative References

12.2. Informative References

Authors' Addresses