One document matched: draft-farrer-softwire-br-multiendpoints-00.xml

<?xml version="1.0" encoding="US-ASCII"?>

<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2473 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!ENTITY rfc6269 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
]>

<rfc category="std" docName="draft-farrer-softwire-br-multiendpoints-00" ipr="trust200902">

<front>
  <title abbrev="BR Multi-endpoints">Multiple Tunnel Endpoints on Border Router</title>

  <author fullname="Ian Farrer" initials="I." surname="Farrer">
      <organization>Deutsche Telekom AG</organization>
      <address>
        <postal>
          <street>CTO-ATI,Landgrabenweg 151</street>
          <city>Bonn</city>
          <region>NRW</region>
          <code>53227</code>
          <country>Germany</country>
        </postal>
        <email>ian.farrer@telekom.de</email>
      </address>
  </author>

  <author fullname="Qi Sun" initials="Q." surname="Sun">
    <organization>Deutsche Telekom AG</organization>
    <address>
      <postal>
        <street>CTO-ATI,Landgrabenweg 151</street>
        <city>Bonn</city>
        <region>NRW</region>
        <code>53227</code>
        <country>Germany</country>
      </postal>
      <email>qui.sun@external.telekom.de</email>
    </address>
  </author>
      

  <date year="2015"/>

  <workgroup>Softwire Working Group</workgroup>

  <abstract>
    <t>This document defines a mechanism to enable an IPv4-over-IPv6
    Softwire Border Router to support multiple tunnel endpoint on 
    one BR instance. This feature can be used to group users based 
    on IPv6 tunnel endpoint addresses and achieve high availability. 
    </t>
  </abstract>

  <note title="Requirements Language">
    <t>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 
    <xref target="RFC2119"/>.</t>
  </note>

</front>

<middle>
    <section title="Introduction" anchor="Introduction">
      <t>The Softwire WG has developed a number of IPv4-over-IPv6 transition 
      mechanisms that utilize a hub-and-spoke network architecture. Although 
      the schema for configuring an BR varies according to the mechanism being
      implemented (using either a per-subscriber rule or an algorithmic mapping
      rule), in their current shape all mechanisms only allow for a single IPv6
      address to be used as the BR's IPv6 tunnel address. This address is
      provisioned to all Softwire Initiators to use as the destination address
      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.</t>
      
      <t>The inherent limitation in having only a single IPv6 tunnel endpoint
      address available for the BR is that it is not possbile to differentiate
      client's tunneled traffic based on BR's address in the encapsulating
      IPv6 packet. However, by implementing multiple IPv6 tunnel endpoint addresses, 
      the BR can support different classes of users, grouped by 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.</t>
      
      <t>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).</t>
      
      <t>This document describes a method that enables one Border Router to serve  
      multiple groups of clients. The BR's mapping/binding table must hold an
      additional "BR source IPv6 address" field for each Softwire Initiator it is
      configured to support.</t>
      
      <t>This mechanism can be applied to lw4over6 <xref target="I-D.ietf-softwire-lw4over6"/>, 
      MAP-E <xref target="I-D.ietf-softwire-map"/> and 
      MAP-T <xref target="I-D.ietf-softwire-map-t"/>.  
      </t>
      
      <t>DISCUSSION - Is this necessary for MAP BRs, or can this already be supported?</t>
      
    </section>

<!---
    <section title="Network Topology">
      <t>One Border Router is capable of serving multiple groups of clients 
      given that it's configured with multiple tunnel endpoint addresses. 
      </t>

        <figure align="center" anchor="topology" title="Topology for multiple 
        tunnel enpoints BR">
          <artwork><![CDATA[

          ]]></artwork>
        </figure>
        
        <t>I've commented this out for now. We can add it in the next rev.</t>

    </section>
--> 
    <section title="Changes to BR's Behavior">
      
<t>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.</t>      
            
      <t>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. 
      </t>
      
      <t>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.</t>
      
      <t>The rest of encapsulation/decapsulation/translation process is aligned with 
      the related mechanisms.
      </t>
      
    </section>
    
    <section title="Changes to Initiator's Behavior">
      <t>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.</t>

<!--
      <t>DISCUSS - What about having multiple tunneling rules on the client as well (with
      associated v4 routes for reachability via the different softwires? I'm not sure
      if this is a good idea, or not - just a suggestion.</t>
      
      <t>[Qi] When you say "multiple tunneling rules", I think that means there would 
      be more than one softwire on one CE. Then the CE MUST be configured with 
      associated v4 routes so that it knows which softwire to use. And those routes
      MUST NOT be the default v4 route, otherwise the other softwire v4 routes would 
      be ignored, right? IMO, it is equivalent to a unified CPE running both MAP-E and
      lw4o6 at the same time, which was considered not necessary, IIRC. </t>
-->

    </section>
    
    <section title="Operational Considerations">
      <t>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, TR69 or out-of-band static configuration. This mechanism is out of  
      scope for this document.</t>
      
      <t>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. </t>
      
      <t>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 <xref target="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.</t>
      
      <t>NOTE: One possible other consideration is that as there is an additional
      lookup action that needs to be carried out for packets at the BR,
      there may be a packet processing overhead.</t>
    </section>
     
    <section title="Security Considerations" anchor="security">
      <t>TBD</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document does not include an IANA request. </t>
    </section>

    <section title="Acknowledgements" anchor="acknowledgements">
      <t>The authors would like to thank Madhusuhdan Vadde for contributions to this
      work. </t>
    </section>

</middle>

<back>

  <references title="Normative References">
    &rfc2119;
    &rfc2473;
  </references>

  <references title="Informative References">
    &rfc6269;
    
    <?rfc include="reference.I-D.ietf-softwire-lw4over6" ?>
    <?rfc include="reference.I-D.ietf-softwire-map" ?>
    <?rfc include="reference.I-D.ietf-softwire-map-t" ?>
    <?rfc include="reference.I-D.ietf-softwire-map-dhcp" ?>
  </references>

</back>

</rfc>