v6ops                                                  V. Kuarsingh, Ed.
Internet-Draft                                     Rogers Communications
Intended status: Informational                                    Y. Lee
Expires: March 16, 2012                                          Comcast
                                                              O. Vautrin
                                                        Juniper Networks
                                                      September 13, 2011

                     6to4 Provider Managed Tunnels


   6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which
   can help manage 6to4 [RFC3056] tunnels operating an an anycast
   [RFC3068] configuration.  The 6to4-PMT framework is intended to serve
   as an option to operators to help improve the experience of 6to4
   operation when conditions of the network may provide sub-optimal
   performance or break normal 6to4 operation. 6to4-PMT provides a
   stable provider prefix and forwarding environment by utilizing
   existing 6to4 Relays with an added function of IPv6 Prefix
   Translation.  This operation may be particularly important in NAT444
   infrastructures where a customer endpoint may be assigned a non-
   RFC1918 address thus breaking the return path for anycast [RFC3068]
   based 6to4 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 March 16, 2012.

Copyright Notice

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

Kuarsingh, et al.        Expires March 16, 2012                 [Page 1]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

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

Kuarsingh, et al.        Expires March 16, 2012                 [Page 2]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

1.  Introduction

   6to4 [RFC3056] tunnelling along with the anycast operation described
   in [RFC3068] is widely deployed in modern Operating Systems and off
   the shelf gateways sold throughout the retail and OEM channels.
   Anycast [RFC3068] based 6to4 allows for tunnelled IPv6 connectivity
   through IPv4 clouds without explicit configuration of a relay
   address.  Since the overall system utilizes anycast forwarding in
   both directions, flow paths are difficult to determine, tend to
   follow separate paths in either direction, and often change based on
   network conditions.  The return path is normally uncontrolled by the
   local operator and can contribute to poor performance for IPv6, and
   can also act as a breakage point.  Many of the challenges with 6to4
   are described in [RFC6343].  A specific critical use case for
   problematic anycast 6to4 operation is related to when the consumer
   endpoints are downstream from a northbound NAT44 function when
   assigned non-RFC1918 addresses (common future case in wireline
   networks and very common in wireless networks).

   Operators which are actively deploying IPv6 networks and operate
   legacy IPv4 access environments may want to utilize the existing 6to4
   behaviour in customer site resident hardware and software as an
   interim option to reach the IPv6 Internet in advance of being able to
   offer full native IPv6.  Operators may also need to address the
   brokenness related to 6to4 operation originating from behind a
   provider NAT function. 6to4-PMT offers an operator the opportunity to
   utilize IPv6 Prefix Translation to enable deterministic traffic flow
   and an unbroken path to and from the Internet for IPv6 based traffic
   sourced originally from these 6to4 customer endpoints.

   6to4-PMT translates the prefix portion of the IPv6 address from the
   6to4 generated prefix 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 primarily intended to be used in a stateless manner to maintain
   many of the elements inherent in normal 6to4 operation.
   Alternatively, 6to4-PMT can be used in a stateful translation mode
   should the operator choose this option.

2.  Motivation

   Many operators endeavour to deploy IPv6 as soon as possible so as to
   ensure uninterrupted connectivity to all Internet applications and
   content through the IPv4 to IPv6 transition process.  The IPv6
   preparations within these organizations are often faced with both
   financial challenges and timing issues related to deploying IPv6 to

Kuarsingh, et al.        Expires March 16, 2012                 [Page 3]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

   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
   [RFC5969], Dual-Stack Lite [RFC6333] and Native Dual Stack.

   Operators face a number of challenges related to home equipment
   replacement.  Operator initiated replacement of this equipment will
   take time due to the nature of mass equipment refresh programs or may
   require the consumer to replace their own gear.  Replacing consumer
   owned and operated equipment, compounded by the fact that there is
   also a general unawareness of what IPv6 is, also adds to the
   challenges faced by operators.  It is also important to note that
   6to4 is found in much of the equipment found in networks today which
   do not as of yet, or will not, support 6RD and/or Native IPv6.

   Operators may still be motivated to provide a form of IPv6
   connectivity to customers and would want to mitigate potential issues
   related to IPv6-only deployments elsewhere on the Internet.
   Operators also need to mitigate issues related to the fact that 6to4
   operation often is on by default and may be subject to erroneous
   behaviour.  The undesired behaviour may be related to the use of non-
   RFC1918 addresses on CPE equipment which operate behind large NATs,
   or other conditions as described in a general advisory as laid out in

   6to4-PMT allows an operator to help mitigate such challenges by
   leveraging the existing 6to4 deployment base, 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.  One of key objectives of 6to4-PMT is to also help reverse
   the negative impacts of 6to4 in NAT444 environments.  The 6to4-PMT
   operation can also be used immediately and the default parameters are
   often enough to allow it to operate in a 6to4-PMT environment.  Once
   native IPv6 is available to the endpoint, the 6to4-PMT operation is
   no longer needed and will cease to be used based on correct address
   selection behaviours in end hosts [RFC3484].

   6to4-PMT thus helps operators remove the impact of 6to4 in NAT444
   environments, deals with the fact that 6to4 is often on by default,
   allows access to IPv6-only endpoints from IPv4-only addressed
   equipment and provides relief from many challenges related to mis-
   configuations in other networks.  Due to the simple nature of 6to4-
   PMT, it can also be implemented in a cost effective and simple manner
   allowing operators to concentrate their energy on deploying Native

Kuarsingh, et al.        Expires March 16, 2012                 [Page 4]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

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 [RFC5969] by decapsulating and forwarding encapsulated 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
   [RFC5969] or traditional 6to4 operation.

   The 6to4-PMT Relay is intended to provide a stateless (or stateful)
   mapping of the 6to4 prefix to a provider supplied prefix.

                             | 6to4-PMT Operation  |

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

                    Figure 1: 6to4-PMT Functional Model

   This mode of operation is seen as beneficial when compared to broken
   6to4 paths and or environments where 6to4 operation may be functional
   but highly degraded.

3.2.  Traffic Flow

   Traffic in the 6to4-PMT model is intended to be controlled by the
   operator's 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 2 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.

Kuarsingh, et al.        Expires March 16, 2012                 [Page 5]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

        |  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           Propagation

                       Figure 2: 6to4-PMT Flow Model

   Traffic between two 6to4 enabled devices would use the IPv4 path for
   communication according to RFC3056. 6to4-PMT is intended to be
   deployed in conjunction with the 6to4 relay function in an attempt to
   help simplify it's deployment.  The model can also provide the
   ability for an operator to forward both 6to4-PMT (translated) and
   normal 6to4 flows (untranslated) simultaneously based on configured

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 [RFC6296].  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 3, or more advanced forms of translation can be used to
   achieve higher address compression.

   Figure 3 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
   gateways, a subnet-id of "0000" is the most common default case.

Kuarsingh, et al.        Expires March 16, 2012                 [Page 6]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

      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 as developed and
   deployed by the vendor community.  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 manage translation state.

   If stateful operation is chosen, the operator would need to validate
   state and routing requirements particular to that type of deployment.
   The full body of considerations for this type of deployment are not
   within this scope of this document.

4.  Deployment Considerations 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
   maintain normal 6to4 operation irrespective of degraded performance.
   In cases where the customer is behind a NAT44 device (Provider CGN),
   the customer would not be advised to opt-out and can also be assisted
   to turn off 6to4.

   Since the 6to4-PMT system is targeted at customers who are relatively
   unaware of IPv6 and IPv4, and normally run network equipment with a

Kuarsingh, et al.        Expires March 16, 2012                 [Page 7]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

   default configuration, an opt-out strategy is recommended.  This
   method provides the 6to4-PMT operation for non-IPv6 savvy customers
   whose equipment may turn on 6to4 automatically and allows savvy
   customers to easily configure their way around the 6to4-PMT function.

   Capable customers can also disable anycast based 6to4 entirely and
   use traditional 6to4 or other tunnelling mechanisms if they are so
   inclined.  This is not considered the normal case, and most endpoints
   with auto-6to4 operation will be subject to 6to4-PMT operation since
   most users are unaware of it's existence. 6to4-PMT is targeted as an
   option for stable IPv6 connectivity for average consumers.

4.2.  Shared Transition Space Considerations

   6to4-PMT operation can also be used to mitigate a known problem with
   6to4 when Shared Transition Space [I-D.weil-shared-transition-space-
   request] or public but non-routed IPv4 space is used.  Public but un-
   routed address space would cause many deployed OSs and network
   equipment to potentially auto-enable 6to4 operation even without a
   valid return path (such as behind a NAT44 provider function).  The
   Operators' desire to use public but un-routed IP space is considered
   highly likely based on points made in [I-D.bdgks-arin-shared-

   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 flow is built using 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 behaviour.

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 of 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.  The lack of transparency is however a better form of
   operation when extreme poor performance, broken IPv6 connectivity, or
   no IPv6 connectivity is considered as the alternative.

4.4.  Routing Requirements

   The provider would need to advertise the anycast IP range within the
   IPv4 routing environment (devices to be serviced) to attract the 6to4

Kuarsingh, et al.        Expires March 16, 2012                 [Page 8]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

   upstream traffic.  To control this environment and make sure all
   northbound traffic lands on a provider BR, the operator may filter
   the anycast range from being advertised from customer endpoints
   toward the network (upstream propagation).

   The provider would not be able to control route advertisements inside
   the customer domain, but this use case is out of this document's
   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 traditional 6to4 traffic
   within their own network (Native IPv6 to 6to4-PMT based endpoint).

4.5.  Relay Deployments

   The 6to4-PMT function can be deployed onto existing 6to4 relays (if
   desired) to help minimize network complexity. 6ot4-PMT has already
   been developed on Linux based platforms which are package add-ons to
   the traditional 6to4 code.  The only additional considerations beyond
   normal 6to4 relay operation would include the need to route specific
   IPv6 provide prefix ranges towards peers and the Internet.

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. 6to4-PMT is
   also not plainly perceptible by external hosts and entities appearing
   as Native IPv6.

7.  Acknowledgements

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

   Additional thanks to the following for assisting with the coding and
   testing of 6to4-PMT: Marc Blanchet, John Cianfarani, and Nik Lavorato

8.  References

Kuarsingh, et al.        Expires March 16, 2012                 [Page 9]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

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

              Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and
              B. Schliesser, "ARIN Draft Policy 2011-5: Shared
              Transition Space",
              draft-bdgks-arin-shared-transition-space-02 (work in
              progress), August 2011.

              Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA Reserved IPv4 Prefix for Shared
              Transition Space",
              draft-weil-shared-transition-space-request-04 (work in
              progress), August 2011.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, June 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6343]  Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
              RFC 6343, August 2011.

Kuarsingh, et al.        Expires March 16, 2012                [Page 10]

Internet-Draft        6to4 Provider Managed Tunnels       September 2011

Authors' Addresses

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

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

   Yiu L. Lee
   One Comcast Center
   Philadelphia, PA  19103

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

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

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

Kuarsingh, et al.        Expires March 16, 2012                [Page 11]