summaryrefslogtreecommitdiffstats
path: root/src/vnet/lisp-gpe/lisp_gpe.c
blob: 8ee2a72d381e607f09449a9cce7bdda608d45129 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
1
.. _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/>`__.
='n574' href='#n574'>574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726