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

Versions: 00 draft-ietf-softwire-4rd

Softwire                                                      O. Vautrin
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                           July 29, 2010
Expires: January 30, 2011


          IPv4 Rapid Deployment on IPv6 Infrastructures (4rd)
                     draft-vautrin-softwire-4rd-00

Abstract

   This document specifies an automatic tunneling mechanism tailored to
   advance deployment of IPv4 to end users via an IPv6 network
   infrastructure.  This document aims at giving an alternative to
   family translation to operate an Ipv6-only network.

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 30, 2011.

Copyright Notice

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




Vautrin                 Expires January 30, 2011                [Page 1]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  4rd Model and operation . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Traffic from CE to IPv4 Internet [CE Behavior]  . . . . . . 5
     4.2.  Traffic from CE to IPv4 Internet [BR Behavior]  . . . . . . 6
     4.3.  Traffic from IPv4 Internet to CE [CE Behavior]  . . . . . . 6
     4.4.  Traffic from IPv4 Internet to CE [BR Behavior]  . . . . . . 6
   5.  IPv6-only Deployment considerations . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8






















Vautrin                 Expires January 30, 2011                [Page 2]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


1.  Introduction

   4rd specifies a protocol mechanism to deploy IPv4 to sites or Host
   via an IPv6 network.  It builds on [I-D.ietf-softwire-ipv6-6rd] and
   [I-D.ietf-softwire-dual-stack-lite]. 4rd could be seen either as the
   opposite of [I-D.ietf-softwire-ipv6-6rd] or as
   [I-D.ietf-softwire-dual-stack-lite] without NAT (or leaving NAT as
   optional).

   IPv6-only network are not common.  But Ipv6-only networks is the end
   goal in the Ipv4 to IPv6 transition.  Thus it is worthwhile to define
   viable mechanism to ease the use of Ipv6-only network.  The
   alternatives to 4rd are defined in [I-D.ietf-behave-v6v4-framework]
   and such mechanisms have well known limitation most of them described
   in [RFC4966].

   The 4rd mechanism relies upon a tunneling of IPv4 inside IPv6 to a
   well known IPv6 address to allow automatic IPv4 operation in an IPv6-
   only Network.  The mechanism can be stateless or stateful depending
   on the selection of the IPv6 address.  If the Ipv6 address is using
   the IPv4-Embedded IPv6 Address Format described in
   [draft-ietf-behave-address-format] then the 4rd operation will be
   stateless.  If the algorithmic mapping is not used, 4rd will fall
   back to a Standard DS-Lite operation. 4rd views the IPv6 network as a
   link layer for IPv4 and supports an automatic tunneling abstraction
   similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model.

   A 4rd domain consists of 4rd Customer Edges (CE) and one or more 4rd
   Border Relays (BRs).  IPv4 packets encapsulated by 4rd follow the
   IPv6 routing topology within the network among CEs and BRs. 4rd BRs
   are traversed only for IPv4 packets that are destined to or are
   arriving from outside the 4rd domain.  The CE can be either a host
   (which would need to have a 4rd client capability) or a router (On
   the LAN side of the router, IPv4 is implemented as it would be for
   any native IP service delivered by the network).

   4rd relies on IPv6 and is designed to deliver production-quality IPv4
   alongside IPv6 with as little change to IPv6 networking and
   operations as possible. 4rd can be deployed and thus remove the need
   for a Dual stack Network completely helping the transition to a full
   IPv6 internet in the future.

   4rd used with a short IPv4 DHCP lease time or in conjunction with
   NAT44 (DS-Lite) can also be seen as an IPv4-depletion mitigation
   solution.






Vautrin                 Expires January 30, 2011                [Page 3]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


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

   4rd_IPv4_prefix - An IPv4 prefix selected for use by a 4rd domain.
   There is exactly one 4rd IPv4-prefix for a given 4rd domain.  A
   network may deploy 4rd with a single 4rd domain or multiple 4rd
   domains.

   4rd Customer Edge - A 4rd CE is a device functioning as a Customer
   Edge in a 4rd deployment.  A 4rd CE may also be referred simply as a
   "CE" within the context of 4rd.

   4rd domain - A set of 4rd CEs and BRs connected to the same virtual
   4rd link.

   4rd Border Relay (BR) - A 4rd-enabled router managed at the edge of a
   4rd domain.  A border relay router has at least one of each of the
   following: an IPv6-enabled interface, a 4rd virtual interface acting
   as an endpoint for the 4rd IPv4 in IPv6 tunnel, and an IPv4 interface
   connected to the native IPv4 network.  A 4rd BR may also be referred
   to simply as a "BR" within the context of 4rd.

   BR_IPv6_address - The IPv6 address of the 4rd Border Relay for a
   given 4rd domain.  This IPv6 address is used by the CE to send
   packets to a BR in order to reach IPv4 destinations outside of the
   4rd domain.

   CE_IPv6_address - The IPv6 address given to the CE through normal
   means (i.e., configured via DHCP, or otherwise).  With proper DHCP
   and Network design planning, this address can match the
   CE_IPv4_address that the CE will receive and thus use an IPv4-
   Embedded IPv6 Address Format described in
   [draft-ietf-behave-address-format]).

   CE_IPv4_address - The IPv4 address given to the CE through the IPv6
   tunnel (i.e., configured via DHCP, or otherwise).  This means the CE
   can only get its CE_IPv4_address when it already has an
   CE_IPv6_address.  This address may be global or private [RFC1918].
   This address is used to send and receive IPv4 packets.






Vautrin                 Expires January 30, 2011                [Page 4]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


4.  4rd Model and operation



          4rd-sites        IPv6-Only Zone       IPv4-Only Zone
           __/\__     ________/\__________   __________/\_________
         /        \ /                     \/                       \

         4rd-CEs
            |                                 4rd-relays
            |
            V            (IPv6 routing)           |
                    _________________________     |
           IPv4    |                         |    V
          & IPv6   |                         |    ___
            _|__   <= SiteV6Address(X)       |   |   |
           | |  |  |        .----------------|---|   |----
           |  X |--|-.     /                 |   |___|
           |____|  |  \   /                  |          (IPv4 routing)
         Host-only |   \ /                   |
            CE     |    O      BR_IPv6_address   => <= 4rd_IPv4_prefix
             ___   |   / \         (anycast) |
         |  |   |  |  /   \                  |    ___
         |--| Y |--|-'     \                 |   |   |
         |  |___|  |        '----------------|---|   |----
         |  Router <= SiteV6Address(Y)       |   |___|
         |   CE    |                         |
         |         |_________________________|
         IPv4       IPV4 ENCAPSULATED IN IPV6
         & IPv6


                          THE 4RD MODEL



                                 Figure 1

4.1.  Traffic from CE to IPv4 Internet [CE Behavior]

   the CE encapsulate the IPv4 packet into an IPv6 tunnel (aka
   Softwire).  The IPv4 source packet can be either private or public.
   It can be learned through the IPv6 tunnel or by other means.  The
   Ipv6 source address can be either an IPv4-Embedded IPv6 Address or
   not.  The choice to use IPv4-Embedded IPv6 Address or not will have
   an impact on the BR as this will switch between the stateless mode or
   the stateful mode.




Vautrin                 Expires January 30, 2011                [Page 5]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


4.2.  Traffic from CE to IPv4 Internet [BR Behavior]

   If the IPv6 packet source address is using an IPv4-Embedded IPv6
   Address, then in this direction the BR just decapsulate the IPv4
   packets from the IPv6 tunnel and forward it to the IPv4 Internet.
   This is what we call the Stateless 4rd mode.  If the CE_IPv6_address
   is *not* using an IPv4-Embedded IPv6 Address, then the BR need to
   keep track of the relationship of this IP session and the Ipv6
   tunnel.  The IPv6 address becomes the ID of the session.  This is
   what we call the Stateful 4rd mode.

   The BR is either doing NAT44 with the IPv6 address as the host
   identifier if the CE_IPv4_address is a private address or the BR is
   creating a mapping table between the softwire ID and the
   CE_IPv4_address if this last one is public and should not be
   modified.  Note that 1:N NAPT can be used in parallel either on the
   same device or on another one.  This mechanism is then similar to DS-
   Lite.

4.3.  Traffic from IPv4 Internet to CE [CE Behavior]

   The CE decapsulate the IPv4 packets from the IPv6 packets.

4.4.  Traffic from IPv4 Internet to CE [BR Behavior]

   If a session or a mapping information already exist in the system
   that matches the IPv4 packets, the IPv6 packets will be created with
   the information based on this session information.  The session can
   exist because of traffic that originated from the Ipv6 side or
   because some Port or address forwarding have been configured on the
   BR.  If no sessions exist, the stateless mechanism will be used and
   the IPv6 packets will be created using the IPv4 address as defined by
   the IPv4 Mapped address mapping.


5.  IPv6-only Deployment considerations

   - Scenario 1: Service Provider with IPv6-only access would like to
   give an IPv4 address to end subscribers.

   4rd used with a short IPv4 DHCP lease time or in conjunction with
   NAT44 (DS-Lite) can also be seen as an IPv4-depletion mitigation
   solution.  With more and more internet content accessible through
   IPv6, An Ipv4 address could be needed in the future just to access
   some legacy content.  This means an Ipv4 address could be needed only
   temporarily.  This means temporary allocation of Ipv4 addresses with
   short lease time can be a useful IPv4-depletion mitigation solution.




Vautrin                 Expires January 30, 2011                [Page 6]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


   - Scenario 2: An IPv6-only Enterprise would like to give IPv4
   connectivity.

   In this case, operating systems would have to support 4rd the same
   way current operating systems support 6to4, Teredo or ISATAP.  An
   alternative would be to deploy island of IPv4 with 4rd Clients
   running on routers.

   - Scenario 3: An IPv6-only Enterprise would like to restore their
   servers connectivity from IPv4 Internet.  In this case, the 4rd
   client will be started either on the server itself or on the 1st hop
   router.


6.  Acknowledgements

   None


7.  IANA Considerations

   None


8.  Security Considerations

   To be defined.


9.  Normative References

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-09 (work in progress),
              May 2010.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-Stack Lite Broadband Deployments
              Following IPv4 Exhaustion",
              draft-ietf-softwire-dual-stack-lite-05 (work in progress),
              July 2010.

   [I-D.ietf-softwire-ipv6-6rd]
              Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10
              (work in progress), May 2010.



Vautrin                 Expires January 30, 2011                [Page 7]


Internet-Draft         4rd (IPv4 Rapid Deployment)             July 2010


   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              August 1996.

   [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

   Olivier Vautrin
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: Olivier@juniper.net































Vautrin                 Expires January 30, 2011                [Page 8]


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