The masquerading proxy is an SR endpoint behavior for processing SRv6 traffic on behalf of an SR-unaware SF. This proxy thus receives SR traffic that is formed of an IPv6 header and an SRH on top of an inner payload. The masquerading behavior is independent from the inner payload type. Hence, the inner payload can be of any type but it is usually expected to be a transport layer packet, such as TCP or UDP.

A masquerading SR proxy segment is associated with the following mandatory parameters:

S-ADDR: Ethernet or IPv6 address of the SF
IFACE-OUT: Local interface for sending traffic towards the SF
IFACE-IN: Local interface receiving the traffic coming back from the SF

A masquerading SR proxy segment is thus defined for a specific SF and bound to a pair of directed interfaces or sub-interfaces on the proxy. As opposed to the static and dynamic SR proxies, a masquerading segment can be present at the same time in any number of SR SC policies and the same interfaces can be bound to multiple masquerading proxy segments. The only restriction is that a masquerading proxy segment cannot be the last segment in an SR SC policy.

The first part of the masquerading behavior is triggered when the proxy node receives an IPv6 packet whose Destination Address matches a masquerading proxy segment. The proxy inspects the IPv6 extension headers and substitutes the Destination Address with the last segment in the SRH attached to the IPv6 header, which represents the final destination of the IPv6 packet. The packet is then sent out towards the SF.

The SF receives an IPv6 packet whose source and destination addresses are respectively the original source and final destination. It does not attempt to inspect the SRH, as RFC8200 specifies that routing extension headers are not examined or processed by transit nodes. Instead, the SF simply forwards the packet based on its current Destination Address. In this scenario, we assume that the SF can only inspect, drop or perform limited changes to the packets. For example, Intrusion Detection Systems, Deep Packet Inspectors and non-NAT Firewalls are among the SFs that can be supported by a masquerading SR proxy.

The second part of the masquerading behavior, also called de- masquerading, is an inbound policy attached to the proxy interface receiving the traffic returning from the SF, IFACE-IN. This policy inspects the incoming traffic and triggers a regular SRv6 endpoint processing (End) on any IPv6 packet that contains an SRH. This processing occurs before any lookup on the packet Destination Address is performed and it is sufficient to restore the right active segment as the Destination Address of the IPv6 packet.

For more information, please see draft-xuclad-spring-sr-service-chaining.

CLI configuration

The following command instantiates a new End.AM segment that sends masqueraded traffic on interface IFACE-OUT towards an appliance at address S-ADDR and restores the active segment in the IPv6 header of the packets coming back on interface IFACE-IN.

1 sr localsid address SID behavior end.am nh S-ADDR oif IFACE-OUT iif IFACE-IN

For example, the below command configures the SID 1::A1 with an End.AM function for sending traffic on interface GigabitEthernet0/8/0 to the appliance at address A1::, and receiving it back on interface GigabitEthernet0/9/0.

1 sr localsid address 1::A1 behavior end.am nh A1:: oif GigabitEthernet0/8/0 iif GigabitEthernet0/9/0

Pseudocode

Masquerading

Upon receiving a packet destined for S, where S is an IPv6 masquerading proxy segment, a node N processes it as follows.

 IF NH=SRH & SL > 0 THEN
     Update the IPv6 DA with SRH[0]
     Forward the packet on IFACE-OUT
 ELSE
     Drop the packet

De-masquerading

Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N processes it as follows.

 IF NH=SRH & SL > 0 THEN
     Decrement SL
     Update the IPv6 DA with SRH[SL]                             ;; Ref1
     Lookup DA in appropriate table and proceed accordingly

Ref1: This pseudocode can be augmented to support the Penultimate Segment Popping (PSP) endpoint flavor. The exact pseudocode modification are provided in draft-filsfils-spring-srv6-network-programming.