.. _srv6_am_plugin_doc:
SRv6 masquerading
=================
SRv6 endpoint to SR-unaware appliance via masquerading (End.AM)
---------------------------------------------------------------
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 <https://datatracker.ietf.org/doc/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``.
::
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``.
::
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 <https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/>`__.
