Internet Engineering Task Force T. Murakami, Ed.
Internet-Draft IP Infusion
Intended status: Standards Track G. Chen
Expires: January 5, 2012 H. Deng
China Mobile
W. Dec
Cisco Systems
S. Matsushima
SoftBank Telecom
July 4, 2011
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 5, 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
Murakami, et al. Expires January 5, 2012 [Page 1]
Internet-Draft 4via6-stateless-translation July 2011
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 4via6 Translation Framework . . . . . . . . . . . . . . . . . . 4
5. Stateless Translation Algorithm . . . . . . . . . . . . . . . . 5
6. Behavior of 4via6 Stateless Translation . . . . . . . . . . . . 5
6.1. Behavior on 4via6 CE . . . . . . . . . . . . . . . . . . . 5
6.2. Behavior on 4via6 BR . . . . . . . . . . . . . . . . . . . 6
7. Path MTU and Fragmentation Consideration . . . . . . . . . . . 6
8. Comparison with 4rd . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Murakami, et al. Expires January 5, 2012 [Page 2]
Internet-Draft 4via6-stateless-translation July 2011
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"
Murakami, et al. Expires January 5, 2012 [Page 3]
Internet-Draft 4via6-stateless-translation July 2011
(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 \ /
". ,-' `-. ,-'
`-------' `------'
Figure 1: Network Topology
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
Murakami, et al. Expires January 5, 2012 [Page 4]
Internet-Draft 4via6-stateless-translation July 2011
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
Murakami, et al. Expires January 5, 2012 [Page 5]
Internet-Draft 4via6-stateless-translation July 2011
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.
Murakami, et al. Expires January 5, 2012 [Page 6]
Internet-Draft 4via6-stateless-translation July 2011
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
[I-D.murakami-softwire-4rd]
Murakami, T. and T. Troan, "IPv4 Residual Deployment on
IPv6 infrastructure - protocol specification (work in
progress)", June 2011.
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Murakami, et al. Expires January 5, 2012 [Page 7]
Internet-Draft 4via6-stateless-translation July 2011
12.2. Informative References
[I-D.despres-softwire-sam]
Despres, R., "Stateless Address Mapping (SAM) - a
Simplified Mesh-Softwire Model",
draft-despres-softwire-sam-01 (work in progress),
July 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[I-D.operators-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-operators-softwire-stateless-4v6-motivation-02 (work
in progress), June 2011.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
Murakami, et al. Expires January 5, 2012 [Page 8]
Internet-Draft 4via6-stateless-translation July 2011
Authors' Addresses
Tetsuya Murakami (editor)
IP Infusion
1188 East Arques Avenue
Sunnyvale
USA
Email: tetsuya@ipinfusion.com
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: chengang@chinamobile.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.
Beijing 100053
P.R.China
Phone: +86-13910750201
Email: denghui02@gmail.com
Wojciech Dec
Cisco Systems
Haarlerbergpark Haarlerbergweg 13-19
Amsterdam, NOORD-HOLLAND 1101 CH
Netherlands
Phone:
Email: wdec@cisco.com
Murakami, et al. Expires January 5, 2012 [Page 9]
Internet-Draft 4via6-stateless-translation July 2011
Satoru Matsushima
SoftBank Telecom
1-9-1 Higashi-Shinbashi, Munato-ku
Tokyo
Japan
Email: satoru.matsushima@tm.softbank.co.jp
Murakami, et al. Expires January 5, 2012 [Page 10]