5. Intra-SR-Domain Deployment Model

The use of the SIDs exclusively within the SR domain and solely for packets of the SR domain is an important deployment model.

This enables the SR domain to act as a single routing system.

This section covers:

securing the SR domain from external attempts to use its SIDs
using the SR domain as a single system with delegation between components
handling packets of the SR domain

5.1. Securing the SR Domain

Nodes outside the SR domain are not trusted: they cannot directly use the SIDs of the domain. This is enforced by two levels of access control lists:

Any packet entering the SR domain and destined to a SID within the SR domain is dropped. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:
- Allocate all the SIDs from a block S/s
- Configure each external interface of each edge node of the domain with an inbound infrastructure access list (IACL) that drops any incoming packet with a destination address in S/s
- Failure to implement this method of ingress filtering exposes the SR domain to source-routing attacks, as described and referenced in [RFC5095]
The distributed protection in #1 is complemented with per-node protection, dropping packets to SIDs from source addresses outside the SR domain. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:
- Assign all interface addresses from prefix A/a
- At node k, all SIDs local to k are assigned from prefix Sk/sk
- Configure each internal interface of each SR node k in the SR domain with an inbound IACL that drops any incoming packet with a destination address in Sk/sk if the source address is not in A/a.

5.2. SR Domain as a Single System with Delegation among Components

All intra-SR-domain packets are of the SR domain. The IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.

All interdomain packets are encapsulated for the part of the packet journey that is within the SR domain. The outer IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.

As a consequence, any packet within the SR domain is of the SR domain.

The SR domain is a system in which the operator may want to distribute or delegate different operations of the outermost header to different nodes within the system.

An operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain and delegate validation of the contents of any SRH to a more trusted router or switch attached to the host. Consider a top-of-rack switch T connected to host H via interface I. H receives an SRH (SRH1) with a computed HMAC via some SDN method outside the scope of this document. H classifies traffic it sources and adds SRH1 to traffic requiring a specific Service Level Agreement (SLA). T is configured with an IACL on I requiring verification of the SRH for any packet destined to the SID block of the SR domain (S/s). T checks and verifies that SRH1 is valid and contains an HMAC TLV; T then verifies the HMAC.

An operator of the SR domain may choose to have all segments in the SR domain verify the HMAC. This mechanism would verify that the SRH Segment List is not modified while traversing the SR domain.

5.3. MTU Considerations

An SR domain ingress edge node encapsulates packets traversing the SR domain and needs to consider the MTU of the SR domain. Within the SR domain, well-known mitigation techniques are RECOMMENDED, such as deploying a greater MTU value within the SR domain than at the ingress edges.

Encapsulation with an outer IPv6 header and SRH shares the same MTU and fragmentation considerations as IPv6 tunnels described in [RFC2473]. Further investigation on the limitation of various tunneling methods (including IPv6 tunnels) is discussed in [INTAREA-TUNNELS] and SHOULD be considered by operators when considering MTU within the SR domain.

5.4. ICMP Error Processing

ICMP error packets generated within the SR domain are sent to source nodes within the SR domain. The invoking packet in the ICMP error message may contain an SRH. Since the destination address of a packet with an SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet.

For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol-error handlers.

Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper-layer header.
- If routing header is type 4 Segment Routing Header (SRH)
  
  o The SID at Segment List[0] may be used as the destination address of the invoking packet.

ICMP errors are then processed by upper-layer transports as defined in [RFC4443].

For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in [RFC2473].

5.5. Load Balancing and ECMP

For any interdomain packet, the SR source node MUST impose a flow label computed based on the inner packet. The computation of the flow label is as recommended in [RFC6438] for the sending Tunnel End Point.

For any intradomain packet, the SR source node SHOULD impose a flow label computed as described in [RFC6437] to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH.

At any transit node within an SR domain, the flow label MUST be used as defined in [RFC6438] to calculate the ECMP hash toward the destination address. If a flow label is not used, the transit node would likely hash all packets between a pair of SR Edge nodes to the same link.

At an SR segment endpoint node, the flow label MUST be used as defined in [RFC6438] to calculate any ECMP hash used to forward the processed packet to the next segment.

5.6. Other Deployments

Other deployment models and their implications on security, MTU, HMAC, ICMP error processing, and interaction with other extension headers are outside the scope of this document.