Network Working Group D. Shytyi Internet-Draft Individual Intended status: Standards Track 10 August 2024 Expires: 11 February 2025 Segment Routing IPv6 Locator Auto Configuration draft-shytyi-spring-sr6lac-01 Abstract This documents provides the specification of the steps a node 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. 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. Shytyi Expires 11 February 2025 [Page 1] Internet-Draft SRv6 Locator Auto Configuration August 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Design purpose . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol speficication . . . . . . . . . . . . . . . . . . . 3 4.1. Creation of SRv6 Locators . . . . . . . . . . . . . . . . 4 4.1.1. Sending Router Solicitations . . . . . . . . . . . . 4 4.1.2. Receiving Router Solicitations . . . . . . . . . . . 4 4.1.2.1. SRv6 Duplicate Locator Detection . . . . . . . . 4 4.1.3. Sending Router Advertisement . . . . . . . . . . . . 5 4.1.4. Processing Router Advetisements . . . . . . . . . . . 5 4.1.5. Router Advertisement not Received . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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]. Shytyi Expires 11 February 2025 [Page 2] Internet-Draft SRv6 Locator Auto Configuration August 2024 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. Shytyi Expires 11 February 2025 [Page 3] Internet-Draft SRv6 Locator Auto Configuration August 2024 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 node MAY send Router Solicitations as specified in RFC 4861 [RFC4861]. A node 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 node 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 nodes 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 node. 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 Shytyi Expires 11 February 2025 [Page 4] Internet-Draft SRv6 Locator Auto Configuration August 2024 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: Shytyi Expires 11 February 2025 [Page 5] Internet-Draft SRv6 Locator Auto Configuration August 2024 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 node SHOULD peform 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 Shytyi Expires 11 February 2025 [Page 6] Internet-Draft SRv6 Locator Auto Configuration August 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . Author's Address Dmytro Shytyi Individual Paris area France Email: dmytro@shytyi.net URI: https://dmytro.shytyi.net Shytyi Expires 11 February 2025 [Page 7]