| Internet-Draft | Abbreviated Title | January 2025 |
| Yu | Expires 5 July 2025 | [Page] |
This document extends the Segment Routing over IPv6 (SRv6) Network Programming framework [RFC8986] by incorporating group-based policy capabilities.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 July 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Group-based Policy (GBP) [GROUPBASEDPOLICY] initially was .It abstractions provide an intent-driven declarative policy model that presents simplified application-oriented interfaces to the user. Group-Based Policy (GBP) is a critical concept in networking and security, particularly in environments like Software-Defined Networking (SDN), cloud computing, and enterprise networks. It provides a flexible and scalable way to manage network policies based on groups of endpoints rather than individual devices, IP addresses, or flows.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
GBP: Group-based Policy described in [GROUPBASEDPOLICY]¶
This documents defines the behaviors of END.DX6 with GBP, END.DX4 with GBP, END.DT6 with GBP, END.DT4 with GBP, END.DT46 with GBP, END.DT2U with GBP by allowing these SID behaviors taking an argument: "Arg.Src-GBP-ID". The Src-GBP-ID info allows endpoint node to determine the behavior (allowed or denied) when traffic is being forwarded to specific host. The allocation of the GBP-id argument values planned gloabally, and the behavior of traffic from one Src-GBP-ID to another Dst-GBP-ID is specified locally. The SRv6 SIDs with the GBP argument mentioned in this document is not signaled to other nodes via the control plane, which means they are local significant only. The control plane process described in [RFC9252] still applies.¶
Group 0 is the default group based policy ID. If no group based policy is specified, then value 0 is used. The default behavior of the group 0 is implementation defined and SHOULD be configurable (allowed/denied).¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX6 with GBP SID, N does the following:¶
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Search GBP matching table with exposed packet and get Dst-GBP-ID
S04. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05. If (Matched){
S06. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07. } Else {
S08. Forward the exposed IPv6 packet to the L3 adjacency J
S09. }
S10. } Else {
S11. Process as per Section 4.1.1 in RFC8986
S12. }
¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX4 with GBP SID, N does the following:¶
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Search GBP matching table with exposed packet and get Dst-GBP-ID
S04. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05. If (Matched){
S06. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07. } Else {
S08. Forward the exposed IPv4 packet to the L3 adjacency J
S09. }
S10. } Else {
S11. Process as per Section 4.1.1 in RFC8986
S12. }
¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT6 with GBP SID, N does the following:¶
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05. Search GBP matching table with exposed packet and get Dst-GBP-ID
S06. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07. If (Matched){
S08. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09. } Else {
S10. Forward the exposed IPv6 packet to the oIF.
S11. }
S12. } Else {
S13. Process as per Section 4.1.1 in RFC8986
S14. }
¶
An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.¶
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Search GBP matching table with exposed packet and get Dst-GBP-ID
S04. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05. If (Matched){
S06. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07. } Else {
S08. Set the packet's associated FIB table to T
S09. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S10. }
S11. } Else {
S12. Process as per Section 4.1.1 in RFC8986
S13. }
¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 with GBP SID, N does the following:¶
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05. Search GBP matching table with exposed packet and get Dst-GBP-ID
S06. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07. If (Matched){
S08. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09. } Else {
S10. Forward the exposed IPv4 packet to the oIF.
S11. }
S12. } Else {
S13. Process as per Section 4.1.1 in RFC8986
S14. }
¶
An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.¶
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Search GBP matching table with exposed packet and get Dst-GBP-ID
S04. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05. If (Matched){
S06. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07. } Else {
S08. Set the packet's associated FIB table to T
S09. Submit the packet to the egress IPv4 FIB lookup for transmission to the new destination
S10. }
S11. } Else {
S12. Process as per Section 4.1.1 in RFC8986
S13. }
¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT46 with GBP SID, N does the following:¶
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05. Search GBP matching table with exposed packet and get Dst-GBP-ID
S06. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07. If (Matched){
S08. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09. } Else {
S10. Forward the exposed IPv4 packet to the oIF.
S11. }
S12. } Else If (Upper-Layer header type == 41(IPv6) ) {
S13. Remove the outer IPv6 header with all its extension headers
S14. Set the packet's associated FIB table to T
S15. Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S16. Search GBP matching table with exposed packet and get Dst-GBP-ID
S17. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S18. If (Matched){
S19. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S20. } Else {
S21. Forward the exposed IPv6 packet to the oIF.
S22. }
S23. } Else {
S24. Process as per Section 4.1.1 in RFC8986
S25. }
¶
An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.¶
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Search GBP matching table with exposed packet and get Dst-GBP-ID
S04. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05. If (Matched){
S06. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07. } Else {
S08. Set the packet's associated FIB table to T
S09. Submit the packet to the egress IPv4 FIB lookup for transmission to the new destination
S10. }
S11. } Else If (Upper-Layer header type == 41(IPv6) ) {
S12. Remove the outer IPv6 header with all its extension headers
S13. Search GBP matching table with exposed packet and get Dst-GBP-ID
S14. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S15. If (Matched){
S16. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S17. } Else {
S18. Set the packet's associated FIB table to T
S19. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S20. }
S21. } Else {
S22. Process as per Section 4.1.1 in RFC8986
S23. }
¶
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 SID, N does the following:¶
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Look up the exposed MAC Destination Address in L2 table T
S05. If (matched entry in T with destination oIF) {
S06. Search GBP matching table with exposed packet and get Dst-GBP-ID
S07. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S08. If (Matched){
S09. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S10. } Else {
S11. Forward the exposed packet to oIF
S12. }
S13. } Else {
S14. Forward via all L2 OIFs in table T
S15. }
S16. } Else {
S17. Process as per Section 4.1.1 in RFC8986
S18. }
¶
An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.¶
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Search GBP matching table with exposed packet and get Dst-GBP-ID
S05. Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S06. If (Matched){
S07. Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S08. } Else {
S09. Look up the exposed MAC Destination Address in L2 table T
S10. If (matched entry in T with destination oIF){
S11. Forward the exposed packet to oIF
S12. } Else {
S13. Forward via all L2 OIFs in table T
S14. }
S15. } Else {
S16. Process as per Section 4.1.1 in RFC8986
S17. }
S18. }
¶
The souce node can use various clarification methods to identify the Src-GBP-ID of a host it belongs to.¶
When encapsulating the SRv6 header, the Src-GBP-ID is encapsulated into the argument part of the packet.¶
This document requests the IANA to allocate, within the "SRv6 Endpoint Behaviors" sub-registry beloto the top-level "Segment-routing with IPv6 dataplane (SRv6) Parameters" registry, the following allocations:¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | END.DX6 with GBP | [This document] |
| TBA2 | END.DX4 with GBP | [This document] |
| TBA3 | END.DT6 with GBP | [This document] |
| TBA4 | END.DT4 with GBP | [This document] |
| TBA4 | END.DT46 with GBP | [This document] |
| TBA4 | END.DT2U with GBP | [This document] |
The mechanism described in this document leverage the security rules defined in Section 7 of RFC8986 [RFC8986].¶
This section describes the examples of GBP usage. An implementation is not enforced to achieve all scenarios mentioned in this section.¶
Example 1: Deny traffic from specific Src-GBP-ID = 100 (e.g. traffic from guest network)¶
rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = any, action: deny¶
Example 2: Deny traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. traffic from untrusted host to server)¶
rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: deny¶
Example 3: Redirect L3 traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. to a cleaning device)¶
rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: redirect¶
Example 4: RSPAN traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. to a monitoring device)¶
rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: RSPAN¶