Internet-Draft SRv6 Locator Auto Configuration August 2024
Shytyi Expires 11 February 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-shytyi-spring-sr6lac-00
Published:
Intended Status:
Standards Track
Expires:
Author:
D. Shytyi
Individual

Segment Routing IPv6 Locator Auto Configuration

Abstract

This documents provides the specification of the steps a host is expected to follow for its SRv6 Locator configuration (SR6LAC). The autoconfiguration process generates locators via the the SRv6 Duplicate Locator Detection (SR6DLD) mechanism.

Status of This Memo

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 11 February 2025.

Table of Contents

1. Introduction

This document provides the specification of the steps a host is expected to follow for its SR6LAC. The autoconfiguration procedure includes generating a SRv6 Locator (SR6L) with applying the IPv6 SR6DLD mechanism. The SR6LAC requires no manual configuration of SRv6 Locators on hosts and minimal configuration of routers. The method allows a host to generate its own SR6L using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the SRv6 Block ID, while hosts generate an SRv6 Node ID that uniquely identifies an SRv6 Node in SRv6 Block. An SR6L is formed by combining the two. SR6Ls are leased to a Node for a fixed length of time. Each SR6L has an associated lifetime that indicates how long the SR6L is active. When a lifetime expires, the active status becomes invalid and the SR6L may be reassinged elsewhere in the Internet. The expiration of the SR6L is handled using 2 priorities. In the beginning the SR6L has "high" priority (its usage in communication is unrestricted). After SR6L has "low" priority (its use not suggested, but not strictly forbidden) when waits for invalidation. To ensure theat all configured SR6L are expected to be unique in given SRv6 Block, nodes run a SR6DLD mechanism on SR6L before assigning them. This document defines the SR6DLD algorithm for SRV6 and SRV6 uSID.

2. Terminology

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 RFC 2119 [RFC2119].

SRv6 - Segment Routing over IPv6.

SRv6 uSID - SRv6 micro segment.

SR6L - SRv6 Locator.

SR6LAC - SRv6 Locator Auto Configuration.

SR6DLD - SRv6 Duplicate Locaor Detection.

host - Any node that is not a router.

3. Design purpose

The SR6LAC design purpose listed below:

4. Protocol speficication

SR6LAC is performed on a per-host basis. For multihomed hosts, SR6LAC is performed independently for each SRv6 Block identifier.

4.1. Creation of SRv6 Locators

SR6Ls are formed by appending an Node identificator to a Block identificator of appropriate length. Prefixes are obtained from Prefix Information Options contained in Router Advertisements. Creation of SR6Ls MAY be enabled by default and SHOULD be locally configurable.

4.1.1. Sending Router Solicitations

The Router Advertisement type messages are periodically sent to all nodes via multicast on the link. As an alternative a host MAY send Router Solicitations as specified in RFC 4861 [RFC4861]. A host sends Router Solicitation with flag S in the bit 0 of the RESERVED ICMP field, to the all-routers multicast address, when RS6LACreq is set each "RetransTimer" milliseconds. The IP source address is set to either one of the interface's unicast addresses or the unspecified address as specified in RFC 4861 [RFC4861].

A host whose SR6DLACreq variable is set to 0 MUST not send flag in S in the bit 0 of the RESERVED ICMP field in Router Solicitation.

4.1.2. Receiving Router Solicitations

SRv6 Duplicate Locator Detection MUST be performed for all hosts upon reception of Router Solicitation prior sending Router Advertisement, except the next cases:

  • SR6DLD MUST NOT be performed ouside of SRv6 Block identifier.

  • SR6DLD MUST NOT be performed when unspecified address received. It MUST be dropped by the receiving router as specified in RFC 4861 [RFC4861].

4.1.2.1. SRv6 Duplicate Locator Detection

The mechanism for detecting duplicate SR6Ls uses Router Solicitation and Advertisement messages as described below. If a duplicate SR6L is discovered during the mechanism exectution, the SR6L cannot be assigned to the Host. Note that the mechanism SR6DLD can not guarantee the uniqueness of SR6Ls, as it is possible that duplicated SR6L will still exists (if the link was partioned while SR6DLD was in progress).

If a node receives a Router Solicitation message and the source address not in node's list of registered SR6L, the soliciation is processed as decribed in RFC 4861 [RFC4861]. Further the last 16 bits from source address retreived from the received packet and registered in the list, that further MAY be synhronised with network controller or other nodes. This information MAY be further shared/compared by network controller or via other ways and other Routers that send Router Advertisements may be updated with it.

Else If the target address equal to element from receiving node's SR6L list and the source address is a unicast the solicitation SHOULD be silently ignored. A node MUST NOT respond to a Router Solicitation to a SR6L that is in it's list.

The following functions identify conditions where SR6L MAY be not unique (when two nodes run SR6DLD at the same moment):

  • If the actual number of Router Solicitation received exceeds the number expected, the SR6L is a duplicate.

  • If a Router Solicitation is received before one is sent, the SR6L is duplicate.

4.1.3. Sending Router Advertisement

The Prefix Information forged including the next information:

  • The node sends Router Advertisement with prefix length that MUST NOT be limited by /64 bits prefix lenth to satisfy existing SRv6 formats not just F4816 (prefix length /64 for SRv6) but F3216 (prefix length /48 for SRv6 uSID) and others.

  • The Prefix Information Option has the S-bit that identifies SR6LAC.

    
            0 1 2 3 4 5 6 7
          +-+-+-+-+-+-+-+-+-+
          | | | |S|Reserved1|
          +-+-+-+-+-+-+-+-+-+
    Figure 1: SR6LAC new flag in PIO flags.
    
    

4.1.4. Processing Router Advetisements

If a node receives a Router Advertisement message and the target SR6L is already present, the SR6L is duplicate. Otherwise the SR6LAC is perfomed as exmaple in pseudocode:


1. if  ((PIO received) and
2.     ((SRv6_Block_ID not in SRv6_SID) or
3.     (preffered_lifetime > valid_lifetime))); Then
4.       Ignore PIO;
5. fi
6. if  ((PIO received) and
7.     (SRv6_Block_ID_rcvd not in configured_SR6Ls) and
8.     (vaid_lifetime > 0)
9.      (bit_S in PIO)); Then
10.       node_id_bytes = 0
11.       if (prefix_len_rcvd_bits == 48); Then
12.         node_id_bytes = 8
13.       elseif (prefix_len_rcvd_bits == 32); Then
14.         node_id_bytes = 6
15.       fi
16.       get_random_bytes(&addr, node_id_bytes);
17.       ipv6_addr_prefix_copy(&addr, &SRv6_Block_ID_rcvd, prefix_len_rcvd_bits);
18. fi
            Figure 2: SRv6LAC when processing RA.

4.1.5. Router Advertisement not Received

If a node did not receive a Router Advertisement message after maximum retransmissions of Router Solicitation messages. It indicates that either there are no node that performs router Advertisement, or the address requested is a duplicate. In this case the host SHOULD pefrorm automatically MAC Adress randomisation/change and restart SR6LAC.

5. Security Considerations

No Considerations at this time.

6. IANA Considerations

No request to IANA at this time.

7. Acknowledgements

The authors would like to thank:

for their valuable comments.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.

Author's Address

Dmytro Shytyi
Individual
Paris area
France