Segment Routing IPv6 Locator Auto Configuration

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.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

This document provides the specification of the steps a node 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 nodes and minimal configuration of routers. The method allows a node 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 nodes 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.¶

3. Design purpose

The SR6LAC design purpose listed below:¶

• SR6LAC eliminates the need in manual SRv6 locator configuration of individual nodes before connecting them to the network. SR6LAC assumes that each node can provide a unique SRv6 Node identifier for the SRv6 Block. A SR6L is formed via the combination of SRv6 Block identifier and SRv6 Node identifier.¶

• SR6LAC should falicitate the friendly update of SR6Ls of a site's machines. When a site wish to update all of its nodes SRLs to a new network service provider. Update is achieved through the leasing of SR6Ls and assignment of multiple SR6L to the same node. Lease lifetimes provide a methoud client site switch from old SR6Ls to new ones. The assignment of multiple SR6Ls to node provides a way to transition from old to new ones.¶

4. Protocol speficication

SR6LAC is performed on a per-node basis. For multihomed nodes, SR6LAC is performed independently for each SRv6 Block identifier.¶

• A node MUST maintain a list of SR6Ls with their correspongind lifetimes.¶

• A node MUST allow the SR6DLDreq SR6LAC-related variable to be configured by system management. The value 2 indicates 2 transmissions in total. The Value 0 indicates the SR6DLD MUST NOT be performed.¶

• A node that processes Router Advertisement, MUST maintain a list of SR6Ls.¶

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.

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.¶

Author's Address