[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/