Internet DRAFT - draft-farrer-softwire-br-multiendpoints


Softwire Working Group                                         I. Farrer
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                     Deutsche Telekom AG
Expires: January 7, 2016                                    July 6, 2015

                 Multiple BR Tunnel Endpoint Addresses


   As 'softwire' based approaches for providing IPv4 services to IPv6

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

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

   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 7, 2016.

Copyright Notice

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

Farrer & Sun             Expires January 7, 2016                [Page 1]
Internet-Draft             BR Multi-endpoints                  July 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Analysis of BR Provisioning Approaches  . . . . . . . . . . .   3
     2.1.  Single BR Tunnel Endpoint Approach  . . . . . . . . . . .   3
     2.2.  Per-client Unique BR Tunnel Endpoint Address Approach . .   3
     2.3.  A Mix of Both . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Changes to BR's Behavior  . . . . . . . . . . . . . . . . . .   4
   4.  Changes to Initiator's Behavior . . . . . . . . . . . . . . .   5
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Softwire WG has developed a number of IPv4-over-IPv6 transition
   mechanisms based on a hub-and-spoke network architecture, with the
   Border Router (BR) functioning as the hub.  Although the schema for
   configuring a BR varies according to the mechanism being implemented
   (using either a per-subscriber rule or an algorithmic mapping rule),
   vendor's implementations differ in their approach to the provisioning
   of tunnel endpoints on the BR.  In some implementations, a single
   address must be used for terminating all clients traffic, some
   implementations require every client to use a different tunnel
   endpoint and some employ a 'hybrid' approach, allowing for the
   clients to have unique BR addresses, and other clients to be
   arbrarily grouped with multiple clients using the same BR tunnel
   endpoint address.

   From an operator's standpoint, this difference creates a provisioning
   problem: The values of the parameters with which softwire initiators
   need to be provisioned vary depending on the BR's tunnel endpoint
   provisioning approach.  In a multi-vendor environment, this becomes
   unmanagable and significantly complicates migration of users and geo-
   redundancy between BR's from different vendors.

   This document proposes that the 'hybrid' approach for BR tunnel
   endpoints offers the most flexibility and should be the model
   implemented in softwire concentrators.

Farrer & Sun             Expires January 7, 2016                [Page 2]
Internet-Draft             BR Multi-endpoints                  July 2015

2.  Analysis of BR Provisioning Approaches

2.1.  Single BR Tunnel Endpoint Approach

   In this implementation approach, only a single IPv6 address is used
   as the BR's IPv6 tunnel address.  This address is provisioned to all
   softwire initiators to use as the destination for their IPv4-in-IPv6
   tunneled traffic, and is used by the BR as the source address for
   encapsulated traffic being sent to Softwire initiators.

   The obvious advantage is that all clients can be provisioned with the
   same address for the BR.  In smaller scale deployments, this may be
   sufficient for an operator's needs.  In larger scale deployments,
   this schema makes it difficult to design and plan for the grouping of
   users and geographical failover.

   Only supporting a single IPv6 BR tunnel endpoint address available
   has another limitation: it is not possbile to differentiate client's
   tunneled traffic based on BR's address in the encapsulating IPv6

2.2.  Per-client Unique BR Tunnel Endpoint Address Approach

   In this implementation approach, each client is provisioned with a
   unique /128 address to use as the destination address for their
   tunneled traffic.  The BR is configured with exactly as many unique
   tunnel endpoint addresses as there are softwire initiators.

   The main disadvantage with this approach is that it places an
   additional provisioning overhead on the operator to ensure that each
   client has a unique BR address.  When provisioning lw4o6 using DHCPv6
   as described in [I-D.ietf-softwire-map-dhcp], maintaining per-client
   DHCPv6 entries is a necessary provisioning overhead.  But when
   dynamic provisionig of lw4o6 clients is used [RFC7341], per-client
   entries in the provisioning system are no longer required, as the
   IPv4 addresses for clients are taken from an address pool.  However,
   if each client still needs to be provisioned with a unique tunnel
   endpoint address associated with the IPv4 address it has been
   allocated, then the provisioning model becomes complex and
   potentially unworkable.

2.3.  A Mix of Both

   This document proposes that a BR SHOULD support per-client IPv6
   tunnel endpoints, but not mandate that these addresses are unique.
   E.g., the endpoints can be all the same, or unique, or any
   combination of unique and shared.

Farrer & Sun             Expires January 7, 2016                [Page 3]
Internet-Draft             BR Multi-endpoints                  July 2015

   By implementing multiple IPv6 tunnel endpoint addresses in this
   'mixed' mode, the BR can support different classes of users, grouped
   through their tunnel endpoint address.  Grouping clients based on a
   common tunnel endpoint address makes it simple for intermediate IPv6
   network elements to identify client's traffic group by examining the
   encapsulating IPv6 header, e.g. so that traffic forwarding policies
   can be applied.

   It also allows for flexible, anycast based geographical resilience
   models where each BR supports a primary group of users and a
   secondary group, differentiated by the tunnel endpoint address.
   Traffic is flexibly routed through auto-routing protocols and Equal-
   Cost Multipath (ECMP).

   This document describes a method that enables one Border Router to
   serve in such a mix mode.  The BR's mapping/binding table must hold
   an additional "BR source IPv6 address" field for each Softwire
   Initiator it is configured to support.  The IPv6 addresses of that
   field can be all the same or not, based on the operational

   This mechanism can be applied to lw4over6
   [I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map] and MAP-T

   DISCUSSION - Is this necessary for MAP BRs, or can this already be

3.  Changes to BR's Behavior

   Existing BRs implementing lw4o6, MAP-E or MAP-T are provisioned with
   a set of rules defining packet processing behaviour.  The rule/
   binding table on the Border Router only contains the mapping between
   the IPv6 and IPv4 address and source ports for the Softwire
   Initiators.  In this mechanism, the rule/binding table is extended to
   include the IPv6 tunnel address(es) configured on the BR as another
   field.  The Softwire Initiators' IPv6-IPv4 mapping rules are then
   linked to the related BR's IPv6 tunnel addresses.  As such, it is
   possible for one BR to serve multiple groups of Softwire Initiators,
   independently from each other.

   On receiving an IPv6 packet, the BR MUST use both the source and the
   destination IPv6 addresses as input parameters to search for a
   matching entry in the mapping rule table, instead of only using the
   source IPv6 address/prefix information.  If a successful match is
   made, the encapsulated/translated IPv4 packet is then verified as
   documented in related Softwire mechanisms.

Farrer & Sun             Expires January 7, 2016                [Page 4]
Internet-Draft             BR Multi-endpoints                  July 2015

   When the BR receives a packet from the IPv4 Internet, it looks up for
   the matching entry using the destination IPv4 address and port
   number.  The BR MUST also retrieve the associated BR's IPv6 address
   to use for the encapsulating packet's source IPv6 address.  Depending
   on the implemented mechanism, the mapping rule for constructing the
   destination IPv6 address will need to be retrieved as normal.

   The rest of encapsulation/decapsulation/translation process is inline
   with the related mechanisms.

4.  Changes to Initiator's Behavior

   The Softwire Initiator's behavior is identical to that in the related
   mechanisms.  That is, when it receives an IPv4-in-IPv6 packet it
   checks the source and destination addresses against its
   configuration.  The source address of the packet MUST match the BR's
   tunnel endpoint address configured on the client.

5.  Operational Considerations

   Border Routers need to be provisioned with multiple sets of tunnel
   endpoint IPv6 addresses, IPv4-IPv6 mapping rules for Softwire
   Initiators and routable IPv4 prefixes.  The provisioning mechanisms
   could include NETCONF, TR-69 or out-of-band static configuration.
   This mechanism is out of scope for this document.

   BRs implementing this mechanism can be deployed using IPv6 anycast to
   achieve high availability.  Since multiple IPv6 anycast addresses can
   be configured on the BR as tunnel endpoint addresses, a BR is able to
   serve one primary domain while serving other domains as backup.  The
   BR advertises the IPv6 anycast prefix(es), as well as the routable
   IPv4 prefix(es).  ECMP can be used to leverage for stateless load-
   balancing across multiple BRs.

   However, as the reachable IPv4 customer prefixes are being advertised
   by all instances serving that domain simultanously, IPv4 traffic
   which ingresses the network will, by default, use the cluster which
   has the lowest routing metric to the ingress point in the network.
   This may results in different paths for egress and ingress traffic.
   Whilst stateless and per-subscriber state softwire mechansims
   (described in [RFC6269]) don't require the ingress/egress traffic
   paths to be symmetrical, it may be desirable for an operator to
   engineer this way for effective capacity planning.  The exact
   mechanism for achieving this will be dependant on the network's
   topology and how the operator is utilizes equal-cost multipath based
   load balancing.

   NOTE: Another possible consideration is that as there is an

Farrer & Sun             Expires January 7, 2016                [Page 5]
Internet-Draft             BR Multi-endpoints                  July 2015

   additional lookup action that needs to be carried out for packets at
   the BR, there may be a packet processing overhead.

6.  Security Considerations


7.  IANA Considerations

   This document does not include an IANA request.

8.  Acknowledgements

   The authors would like to thank Madhusuhdan Vadde for contributions
   to this work.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

9.2.  Informative References

              Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
              in progress), November 2014.

              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-13
              (work in progress), March 2015.

              Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              configuration of Softwire Address and Port Mapped
              Clients", draft-ietf-softwire-map-dhcp-12 (work in
              progress), March 2015.

Farrer & Sun             Expires January 7, 2016                [Page 6]
Internet-Draft             BR Multi-endpoints                  July 2015

              Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
              T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work
              in progress), December 2014.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC
              7341, August 2014.

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   CTO-ATI,Landgrabenweg 151
   Bonn, NRW  53227


   Qi Sun
   Deutsche Telekom AG
   CTO-ATI,Landgrabenweg 151
   Bonn, NRW  53227


Farrer & Sun             Expires January 7, 2016                [Page 7]