One document matched: draft-farrer-softwire-br-multiendpoints-01.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">
<!ENTITY rfc7341 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7341.xml">
]>
<rfc category="std" docName="draft-farrer-softwire-br-multiendpoints-01" ipr="trust200902">
<front>
<title abbrev="BR Multi-endpoints">Multiple BR Tunnel Endpoint Addresses</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>As 'softwire' based approaches for providing IPv4 services to IPv6
networks
</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">
<t>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.</t>
<t>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.</t>
<t>This document proposes that the 'hybrid' approach for BR tunnel endpoints
offers the most flexibility and should be the model
implemented in softwire concentrators.</t>
</section>
<section title="Analysis of BR Provisioning Approaches">
<section title="Single BR Tunnel Endpoint Approach">
<t>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.</t>
<t>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.</t>
<t>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 packet.</t>
</section>
<section title="Per-client Unique BR Tunnel Endpoint Address Approach">
<t>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.</t>
<t>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 <xref target="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
<xref target="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.</t>
</section>
<section title="A Mix of Both">
<t>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.
</t>
<t>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.</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
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 requirements. </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>
<!---
<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 inline 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, TR-69 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: Another possible 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;
&rfc7341;
<?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>| PAFTECH AB 2003-2026 | 2026-04-24 15:05:59 |