Segment Routing IPv6 Locator Auto Configuration
draft-shytyi-spring-sr6lac-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Dmytro Shytyi | ||
| Last updated | 2024-08-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-shytyi-spring-sr6lac-01
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,
<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, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
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]