From f47122e07e1ecd0151902a3cabe46c60a99bee8e Mon Sep 17 00:00:00 2001 From: Nathan Skrzypczak Date: Fri, 8 Oct 2021 14:05:35 +0200 Subject: docs: convert plugins doc md->rst Type: improvement Change-Id: I7e821cce1feae229e1be4baeed249b9cca658135 Signed-off-by: Nathan Skrzypczak --- src/plugins/srv6-am/am_plugin_doc.md | 100 ----------------------------------- 1 file changed, 100 deletions(-) delete mode 100644 src/plugins/srv6-am/am_plugin_doc.md (limited to 'src/plugins/srv6-am/am_plugin_doc.md') diff --git a/src/plugins/srv6-am/am_plugin_doc.md b/src/plugins/srv6-am/am_plugin_doc.md deleted file mode 100644 index 11aad855408..00000000000 --- a/src/plugins/srv6-am/am_plugin_doc.md +++ /dev/null @@ -1,100 +0,0 @@ -# SRv6 endpoint to SR-unaware appliance via masquerading (End.AM) {#srv6_am_plugin_doc} - -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/). -- cgit 1.2.3-korg