Individual

Paris area France dmytro@shytyi.net https://dmytro.shytyi.net

Internet Network Working Group srv6, node, locator, autoconfiguration 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.

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.

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. SRv6 - Segment Routing over IPv6. SRv6 uSID - SRv6 micro segment. SR6L - SRv6 Locator. SR6LAC - SRv6 Locator Auto Configuration. SR6DLD - SRv6 Duplicate Locaor Detection.

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.

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.

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.

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

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.

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

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.

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:

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

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.

No Considerations at this time.

No request to IANA at this time.

The authors would like to thank: for their valuable comments.