Multiple Tunnel Endpoints on Border Router

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. 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. 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 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. This mechanism can be applied to lw4over6 , MAP-E and MAP-T . DISCUSSION - Is this necessary for MAP BRs, or can this already be supported?

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. 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 aligned with the related mechanisms.

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.

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. 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 ) 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: 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.

TBD

This document does not include an IANA request.

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