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

Versions: 00 01 02 03 04 05 06 07 RFC 6732

V6ops WG                                               V. Kuarsingh, Ed.
Internet-Draft                                     Rogers Communications
Intended status: Informational                                    Y. Lee
Expires: March 26, 2011                                          Comcast
                                                              O. Vautrin
                                                        Juniper Networks
                                                      September 22, 2010


                     6to4 Provider Managed Tunnels
         draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00

Abstract

   This document provides an overview of a framework describing the
   management of 6to4 [RFC3056] tunnels within a provider network.  The
   6to4 provider managed tunnel, or 6to4-PMT, combines the current
   behavior of 6to4 [RFC3056] utilizing the IPv4 anycast based
   connectivity defined in [RFC3068] along with IPv6 Prefix Translation.
   The framework is intended to allow Service Providers an option to
   translate 6to4 based addresses to provider based addresses utilizing
   provider assigned prefixes.  The framework offers IPv6 connectivity
   to 6to4 compatible endpoints [RFC3056] with the advantage of a stable
   provider assigned prefix.  The 6to4-PMT operation is not intended to
   replace Native IPv6 connectivity nor 6RD, but rather provide a
   connectivity before such options can be deployed by an operator.

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 March 26, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Kuarsingh, et al.        Expires March 26, 2011                 [Page 1]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  6to4 Provider Managed Tunnels . . . . . . . . . . . . . . . . . 4
     3.1.  6to4 Provider Managed Tunnel Model  . . . . . . . . . . . . 4
     3.2.  Traffic Flow  . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Prefix Translation  . . . . . . . . . . . . . . . . . . . . 5
     3.4.  Translation State . . . . . . . . . . . . . . . . . . . . . 6
   4.  Deployment Issues and Requirements  . . . . . . . . . . . . . . 7
     4.1.  Customer Opt-out  . . . . . . . . . . . . . . . . . . . . . 7
     4.2.  ISP Shared Space Interaction  . . . . . . . . . . . . . . . 7
     4.3.  End to End Transparency . . . . . . . . . . . . . . . . . . 8
     4.4.  Routing Requirements  . . . . . . . . . . . . . . . . . . . 8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



















Kuarsingh, et al.        Expires March 26, 2011                 [Page 2]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


1.  Introduction

   6to4 [RFC3056] tunneling is widely deployed in modern host OSs and
   off the shelf gateways sold throughout the retail and OEM channels.
   6to4 allows for tunneled IPv6 connectivity through IPv4 clouds, but
   due to the anycast nature of the ingress and egress flows, flows
   paths are difficult to determine and often change based on network
   conditions.  The return path is uncontrolled by the local provider
   and can contribute to poor performance for IPv6, and can also act as
   a breakage point (i.e. mis-behaving relay/system).  For this reason,
   despite being widely available today, many providers choose not to
   directly support a 6to4 environment.

   Providers which are actively deploying IPv6 networks and operate
   legacy IPv4 access environments may want to utilize the existing 6to4
   behavior in deployed hardware and software and offer a more
   controlled access to the IPv6 Internet for 6to4 capable endpoints.
   6to4-PMT offers a provider the opportunity to utilize IPv6 Prefix
   Translation to provide a more deterministic path to and from the
   Internet for 6to4 based traffic.

   6to4-PMT translates the prefix portion of the address from the 6to4
   address to a provider assigned prefix which is used to represent the
   source.  This translation will then provide a stable forward and
   return path for the 6to4 traffic by allowing the existing IPv6
   routing and policy environment to control the traffic. 6to4-PMT is
   intended to be used in a stateless manner to maintain many of the
   elements inherent in normal 6to4 operation.


2.  Motivation

   Providers endeavor to deploy IPv6 as soon as possible, so as to
   ensure uninterrupted connectivity to all Internet applications and
   content through the transition process.  The IPv6 preparations within
   these organizations are often faced with both financial challenges
   and timing issues related to deploying IPv6 to the network edge and
   related transition technologies.  Many of the new technologies
   addressing IPv4 to IPv6 transition will require the replacement of
   the customer CPE to support technologies like 6RD [RFC5569].

   Provider initiated replacement of this equipment will take time due
   to the nature of such mass equipment refresh programs.  Additionally,
   many providers also do not supply CPE related equipment and general
   lack of awareness in the consumer space may delay the upgrade of many
   in-home gateway and operating environments.  Providers may still be
   motivated to provide a form of IPv6 connectivity to customers to
   mitigate potential issues related to IPv6-only deployments elsewhere



Kuarsingh, et al.        Expires March 26, 2011                 [Page 3]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


   on the Internet.  After IPv4 run out, IPv6 content may grow rapidly
   and in some cases, IPv4 may not be a connection option for some web
   based content providers or the remote host (IPv6 Only).

   6to4-PMT allows a provider to help mitigate such challenges by
   leveraging a protocol which is already found on many CPE home
   gateways, while maintaining operator control of access to the IPv6
   Internet.  It is intended for use when better options, such as 6RD or
   native IPv6, are not yet viable.  The 6to4-PMT operation can also be
   used immediately with existing OS and gateway functionality (in the
   wild) without the initial costly replacement of consumer equipment.
   The default 6to4 operation on most consumer grade OSs and gateways
   will allow for IPv6 connectivity over the IPv4 access network.  Once
   native IPv6 is available to the endpoint, the 6to4-PMT operation is
   not longer needed.  Next step options can include 6RD or Native IPv6.
   6to4-PMT offers an opportunity to fill the gap between now and when
   the provider can feasibly replace the CPE equipment.


3.  6to4 Provider Managed Tunnels

3.1.  6to4 Provider Managed Tunnel Model

   The 6to4 managed tunnel model behaves like a standard 6to4 service
   between the customer IPv6 host or gateway and the 6ot4-PMT Relay
   (within the provider domain).  The 6to4-PMT Relay shares properties
   with 6RD [RFC5569] by decapsulating and forwarding embedded IPv6
   flows, within an IPv4 packet, to the IPv6 Internet.  The model
   provides an additional function which translates the source 6to4
   prefix to a provider assigned prefix which is not found in 6RD
   [RFC5569] or normal 6to4 operation.

   The 6to4-PMT Relay is intended to provide a stateless mapping of the
   6to4 prefix to a provider supplied prefix by mapping the embedded
   IPv4 address in the 6to4 prefix to the provider prefix.


                             | 6to4-PMT Operation  |

          +-----+ 6to4 Tunnel +--------+  +------+  IPv6    +----+
          | CPE |-------------|6to4 BR |--| PT66 |--------- |Host|
          +-----+    IPv4     +--------+  +------+ Provider +----+
                    Network                         Prefix
                               Unified or Separate
                                Functions/Platforms

                    Figure 1: 6to4-PMT Functional Model




Kuarsingh, et al.        Expires March 26, 2011                 [Page 4]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


3.2.  Traffic Flow

   Traffic in the 6to4-PMT model is intended to be controlled by the
   operators IPv6 peering operations.  Egress traffic is managed through
   outgoing routing policy, and incoming traffic is influenced by the
   operator assigned prefix advertisements.

   The routing model is as predictable as native IPv6 traffic and legacy
   IPv4 based traffic.  Figure 1 provides a view of the routing topology
   needed to support this relay environment.  The diagram references
   PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32.

        |  6to4 IPv4 Path     |       Native IPv6 Path            |
               -----------       -----------      -------------
              /  IPv4 Net \     /  IPv6 Net  \  / IPv6 Internet \
        +------+         +--------+         +-------+    +---------+
        | CPE  | PrefixA |6to4-PMT| PrefixB |Peering|    |IPv6 HOST|
        +------+         +--------+         +-------+    +---------+
              \           /     \            /  \               /
               ----------        ------------     --------------

                IPv4 6to4       IPv6 Provider       IPv6 Prefix
                 Anycast           Prefix          Advertisement

                       Figure 2: 6to4-PMT Flow Model

   Traffic normally between two 6to4 enabled devices would use the IPv4
   path for communication according to RFC3056

3.3.  Prefix Translation

   The IPv6 Prefix Translation is a key part of the system as a whole.
   The 6to4-PMT framework is a combination of two concepts: 6to4
   [RFC3056] and IPv6 Prefix Translation.  IPv6 Prefix Translation has
   some similarities to concepts discussed in [draft-mrw-behave-nat66].
   The only change in this particular case is that the provider would
   build specific rules on the translator to map the 6to4 prefix to an
   appropriate provider assigned prefix.

   The provider can use any prefix mapping strategy they so choose, but
   the simpler the better.  Simple direct bit mapping can be used such
   as in Figure 2, or more advanced forms of translation can used
   [reference to I-D here] to achieve higher address compression.

   Figure 2 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a
   provider globally unique prefix (2001:db8::/32).  With this simple
   form of translation, there is support for only one Subnet-ID per
   provider assigned prefix.  In characterization of deployed OSs and



Kuarsingh, et al.        Expires March 26, 2011                 [Page 5]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


   gateways, a subnet-id of "0000" is the most common default case.

      Pre-Relayed Packet [Provider Access Network Side]

      0     16      32     48     64    80     96     112    128 Bits
      | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
        2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx
      | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
                 |       |            |      |      |      |
                  ----    ----        |      |      |      |
                      |       |       |      |      |      |
      | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
        2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx
      | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |

      Post-Relayed Packet [Internet Side]

                     Figure 3: 6to4-PMT Prefix Mapping

   Additional prefix compression techniques can be used such as those
   described in [draft-treamblay-pt66-compression].  These techniques
   would allow for a more flexible implementation potentially supporting
   more Subnet-IDs per provider prefix

3.4.  Translation State

   It is preferred that the overall system use deterministic prefix
   translation mappings such that stateless operation can be
   implemented.  This allows the provider to place N number of relays
   within the network without the need to route traffic specifically to
   support 6to4-PMT.

   If stateful operation is used, then the provider would need to force
   all return traffic to pass back through the same relay as the exit
   packets.  The assumption here is that the provider would operate the
   6to4 anycast environment on the IPv4 side of the relay.  To control
   the ingress traffic, the provider would need to craft IPv6 routes
   (more specific then provider assigned prefix) which match the IPv4
   ranges for a given relay.

   Maintaining these additional routes would subject the provider's IPv6
   network to maintaining a number of fragmented IPv4 network router
   (level of fragmentation dependant on network), these routes do not
   need to be advertised to peer networks, nor should hey.







Kuarsingh, et al.        Expires March 26, 2011                 [Page 6]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


4.  Deployment Issues and Requirements

4.1.  Customer Opt-out

   A provider enabling this function should provide a method to allow
   customers to opt-out of such a service should the customer choose to,
   or wish to maintain normal 6to4 operation.

   Since the 6to4-PMT system is targeted at customers who are relatively
   unaware of IPv6 and IPv4, and normally run network equipment with a
   default configuration, an opt-out strategy is preferred.  This method
   provides the 6to4-PMT operation for non-IPv6 savvy customers whose
   equipment may turn on 6to4 automatically.

   Customers who are aware of IPv6 operation can request an opt-out, or
   more appropriately use an automated mechanism to opt-out of the 6to4-
   PMT operation.  One automated opt-out strategy can include the use of
   Subnet-Id triggers (well known IDs which are determined by policy in
   the relay to not be translated).  Other policy based strategies can
   be employed by the provider to enable opt-out.

   Capable customers can also disable 6to4 entirely and use other
   tunneling mechanisms if they are so capable.  This is not considered
   the normal case, and most endpoints with auto-6to4 operation will be
   subject to 6to4-PMT operation operation. 6to4-PMT is targeted as an
   option for deterministic IPv6 connectivity for average consumers

4.2.  ISP Shared Space Interaction

   6to4-PMT operation can also be used to mitigate a known problem with
   6to4 when ISP Shared Space
   [draft-weil-opsawg-provider-address-spaces] is used.  ISP Shared
   Space would cause many deployed OSs and network equipment to
   potentially auto-enable 6to4 operation should non-RFC1918 addressing
   be used on the CPE IPv4 address assignments.

   Such hosts, in normal cases, would send 6to4 traffic to the IPv6
   Internet via the IPv4 anycast relay, which would in fact provide
   broken IPv6 connectivity since the return path is based on an address
   that is not routed or assigned to the source Network.  The use of
   6to4-PMT would help reverse these effects by translating the 6to4
   prefix to a provided assigned prefix, masking this automatic and
   undesired behavior.  It is conceivable that 6to4-PMT can also used to
   help provide 6to4 operation with the use of ISP Shared Space.







Kuarsingh, et al.        Expires March 26, 2011                 [Page 7]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


4.3.  End to End Transparency

   6to4-PMT mode operation removes the traditional end to end
   transparency of 6to4.  Remote hosts would connect to a translated
   IPv6 address versus the original 6to4 based prefix.  This can be seen
   as a disadvantage to the 6to4-PMT system.  This lack of transparency
   should also be contrasted with the normal operating state of 6to4
   which provides uncontrolled and often high latency prone connectivity

4.4.  Routing Requirements

   The provider would need to advertise the anycast IP range within the
   IPv4 routing environment (service customers of interest) to attract
   the 6to4 upstream traffic.  To control this environment and make sure
   all northbound traffic lands on a provider BR, the operator may
   filter the anycast range form being advertised form customer
   endpoints.

   The provider would not be able to control route advertisements inside
   the customer domain, but this use case is out of scope.  It is likely
   in this case the end network/customer understands IPv6 operation and
   is maintaining their own environment.

   The provider would also likely want to advertise the 2002::/16 range
   within their own network to help bridge within their own network
   (Native IPv6 to 6to4-IPv6 based endpoint)


5.  IANA Considerations

   No IANA considerations are defined at this time.


6.  Security Considerations

   6to4-PMT operation would be subject to the same security concerns as
   normal 6to4 operation and with the operation of tunnels.
   Considerations may also include operation modes related to Prefix
   Translation.  Additional considerations may be found after real
   deployment data is gathered or further analysis is made.


7.  Acknowledgements

   Thanks to the following people for their textual contributions and/or
   guidance on 6to4 deployment considerations: Dan Wing, Scott Beuker,
   JF Tremblay, John Brzozowski and Chris Donley




Kuarsingh, et al.        Expires March 26, 2011                 [Page 8]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


8.  References

8.1.  Normative References

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
              RFC 3068, June 2001.

8.2.  Informative References

   [I-D.mrw-behave-nat66]
              Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
              Translation (NAT66)", draft-mrw-behave-nat66-02 (work in
              progress), March 2009.

   [I-D.weil-opsawg-provider-address-space]
              Weil, J., Kuarsingh, V., and C. Donley, "IANA Reserved
              IPv4 Prefix for IPv6 Transition",
              draft-weil-opsawg-provider-address-space-01 (work in
              progress), August 2010.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", RFC 5569, January 2010.


Authors' Addresses

   Victor Kuarsingh (editor)
   Rogers Communications
   8200 Dixie Road
   Brampton, Ontario  L6T 0C1
   Canada

   Email: victor.kuarsingh@rci.rogers.com
   URI:   http://www.rogers.com


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   U.S.A.

   Email: yiu_lee@cable.comcast.com
   URI:   http://www.comcast.com




Kuarsingh, et al.        Expires March 26, 2011                 [Page 9]


Internet-Draft        6to4 Provider Managed Tunnels       September 2010


   Olivier Vautrin
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale, CA  94089
   U.S.A.

   Email: olivier@juniper.net
   URI:   http://www.juniper.net











































Kuarsingh, et al.        Expires March 26, 2011                [Page 10]


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