| Internet-Draft | Lightweight Host Routing using LLDP | March 2025 |
| Filsfils, et al. | Expires 4 September 2025 | [Page] |
Link Layer Discovery Protocol (LLDP) is widely deployed today for discovery of information across network elements like routers, switches, and hosts. This document extends LLDP to allow hosts to advertise their IP prefixes to their attached routers which can then propagate the reachability of these host prefixes into routing protocols for enabling network-wide connectivity.¶
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 4 September 2025.¶
Copyright (c) 2025 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.¶
Link Layer Discovery Protocol (LLDP) [LLDP] is widely deployed today for discovery of information across network elements like routers, switches, and hosts. LLDP is supported by most switches and routers as well as open source implementations available for hosts. The protocol is often used to discover connections between networking elements, build topology information as well as for monitoring and troubleshooting.¶
In a typical layer-3 data center (DC), servers (i.e., hosts) are connected to the leaf routers as show in Figure 1 below. These Layer-3 DCs, which typically run BGP routing protocol, are described in [RFC7938]. These servers run applications either natively or within containers or virtual machines (VMs). These applications are allocated IP addresses from the IP prefixes assigned to the servers. Furthermore, these server IP prefixes need to be advertised into the DC network and beyond via routing protocols to provide reachability for the application. The server IP prefixes used by applications need not be in the same subnet as the layer-3 link that connects the server hosts to leaf routers. This requires a mechanism for the leaf routers to discover the server IP prefixes connected to it.¶
Tier 2 Tier 1 Tier 2
+-----+ +-----+ +-----+
+-------------| T2A |------| T1A |------| T2C |-------------+
| +-----| |--++--| |--++--| |-----+ |
| | +-----+ || +-----+ || +-----+ | |
| | || || | |
| | +-----+ || +-----+ || +-----+ | |
| +-----+-----| T2B |--++--| T1B |--++--| T2D |-----+-----+ |
| | | +---| |------| |------| |---+ | | |
| | | | +-----+ +-----+ +-----+ | | | |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
| T3 | | T3 | <- Leaf Routers -> | T3 | | T3 |
| A | | B | Tier 3 Tier 3 | C | | D |
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
O O O O <- Servers -> O O O O
Typically, the advertisement of server IP prefixes is done by running a BGP stack on the server and establishing BGP sessions to BGP running on the leaf routers. This requires the provisioning of a BGP stack on the host, the configuration a BGP session between the host and the leaf router. There is also the requirement and expectation that the host is able to announce and withdraw the IP prefixes used by applications running on it in a dynamic manner. The leaf routers themselves also run DC routing protocols (BGP being a popular choice) for the further advertisement of the IP prefixes within the DC network and beyond.¶
The deployment and use of LLDP is quite common in the layer-3 DC networks as it aids in topology discovery and troubleshooting. Open source LLDP implementations are also widely deployed between the leaf routers and the hosts connected to them. This document introduces LLDP extensions to enable the hosts to advertise their prefixes that can be discovered by LLDP running on the leaf routers and used for routing of traffic to those prefixes towards the host. The routers can further advertise or withdraw these host IP prefixes discovered via LLDP into the DC routing protocols like BGP [RFC4271], IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340]. This avoids the provisioning and management of BGP on the hosts towards the leaf routers, thereby simplifying operations in certain deployments.¶
As LLDP is not a routing protocol, the specifications in this document is applicable to layer-3 DCs where the hosts are connected via layer-3 interfaces to the leaf routers and the requirement is simply to provide server IP prefix reachability. This solution works for both IPv4/IPv6 prefixes and enables application/container/VM orchestration mechanisms on the hosts to advertise basic routing information related to these prefixes. These orchestration mechanisms typically interact with the LLDP daemon running locally in the user space on the host to announce and withdraw prefix reachability on demand. The details of these orchestration mechanisms are outside the scope of this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The IPv4 and IPv6 Host Prefix TLVs are used by a host to advertise its own local IP Prefixes in the Link Layer Discovery Protocol data unit (LLDPDU) [LLDP]. The format of these TLV is as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | OUI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OUI continued | sub-type | Prefix Block(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
TLV Type: 7 bits size carrying the value 127 that indicates vendor-specific TLV¶
TLV Length: 9 bits size carrying the length of the TLV after the TLV Length field in terms of octets¶
Organization Unique Identifier (OUI): 3 octet field carrying the hexadecimal value 0x00005E that indicates IANA as the organization managing the underlying allocation space¶
Sub-Type: 1-octet field that carries the IANA allocated LLDP TLV sub-type TBD1 for IPv4 and TBD2 for IPv6¶
Prefix Block(s): at least one or more prefix blocks as specified below¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Flags | IGP Algorithm | Metric | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Prefixes | Prefix 1 (variable) ... Prefix N (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Prefix Flags: 1-octet field carrying the IPv4 or IPv6 prefix flag as described below:¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| Reserved | +-+-+-+-+-+-+-+-+
A-Flag: Anycast flag. If set, then the prefixes in the block are anycast.¶
Reserved bits: Reserved for future use and MUST be zero when originated and ignored when received.¶
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| Reserved |L| +-+-+-+-+-+-+-+-+
IGP Algorithm: 1-octet value providing the algorithm associated with the prefixes in the block. The algorithm values are from IGP Algorithm Types registry under the IANA Interior Gateway Protocol (IGP) Parameters.¶
Metric: 1-octet carrying the metric value from the range 0 to 255 associated with the prefixes in the block.¶
Prefix Length: 1-octet carrying the length in bits of each of the prefixes in the block. The valid values are 1-32 for IPv4 and 1-128 for IPv6.¶
List of Prefixes: One or more prefixes where each prefix is encoded up to the number of bits as indicated by the Prefix Length followed by the minimum number of trailing bits needed to make the end of each prefix field falls on an octet boundary. Any trailing bits MUST be set to 0. Thus, each prefix field contains the most significant octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24, 4 octets for prefix length 25 up to 32, and so on.¶
To ensure efficient encoding of the LLDPDU, the following rules apply:¶
All prefixes that have the same properties (i.e., prefix length, flags, metric, and algorithm) MUST be encoded in a single prefix block unless doing so makes the block larger than the size that can be accommodated in a single IPv4/IPv6 Host Prefix TLV.¶
More than one instance of the IPv4 or IPv6 Host Prefix TLV MUST NOT be used unless the prefix blocks to be advertised do not fit into a single TLV instance.¶
If the same prefix is present in multiple TLV instances or prefix blocks, only the first occurrence of that prefix in the LLDPDU MUST be considered and the rest MUST be ignored.¶
LLDP has been extended to support multi-frame LLDPDUs [LLDP-MULTIFRAME]. The above rules also apply to multi-frame LLDPDUs.¶
The LLDP extensions for lightweight host routing in this document enable the advertisement of the prefixes from the host towards its directly connected router. The host includes its local prefixes in the LLDPDU that it sends on its port(s) connected to the router. The router on receiving these LLDPDU discovers the host prefixes and programs them in its forwarding table with the outgoing interface pointing towards the port over which the LLDPDU was received and with the nexthop as the IP address on the host on that port. This nexthop address MAY be the one that is received via the Management Address TLV of LLDP or discovered via a protocol like ARP or ND on that specific interface. The same prefix may be learnt via LLDP from the same or different hosts over different ports; these MAY be installed as an equal cost multipath (ECMP) route by the router.¶
Further the router MAY advertise these host prefixes learnt via LLDP into other protocols like BGP, OSPF, or IS-IS via route redistribution. The details of route redistribution mechanism for conveying information like metric and algorithm along with the prefix are local to the router implementation and outside the scope of this draft.¶
LLDPDUs are sent periodically by the host and the router including the host IP prefixes that are active on the host. The host MAY also trigger an LLDPDU on demand when the set of IP host prefixes that are active change (e.g., when a prefix is removed, or a new prefix is provisioned).¶
The processing of the host IP prefix information on the receiving router side follows the LLDP specification [LLDP]. This includes performing a mark and sweep operation between the existing set of host IP prefixes learnt on a specific port previously against the set of IP prefixes received on the same port in a subsequent LLDPDU. Any newly learnt prefixes are installed in the forwarding and made available for advertisement into other routing protocols via redistribution. Any prefixes that are no longer being received via LLDPDU on that port are deleted from the forwarding and withdrawn from routing protocols where they might have been previously redistributed into.¶
The semantics of the mandatory Time To Live TLV of LLDP [LLDP] also affect the IP host prefix information learnt via LLDP. This includes removing all the learnt IP prefixes if an LLDPDU is not received within the period specified in the previous LLDPDU. Additionally, an implementation SHOULD delete the learnt host IP prefixes as soon as the port over which they are learnt goes down.¶
There is no change the LLDPDUs sent from the routers towards the host.¶
This document requests IANA to allocate code points from the "Link Layer Discovery Protocol (LLDP) TLV Subtypes" registry of the "IANA OUI Ethernet Numbers" registry group.¶
+-------+------------------------------------------+---------------+ | Code | | | | Point | Description | Reference | +-------+------------------------------------------+---------------+ | TBD1 | IPv4 Host Prefix TLV | this document | | TBD2 | IPv6 Host Prefix TLV | this document | +-------+------------------------------------------+---------------+
This document also requests the creation of two registries called "LLDP IPv4 Host Prefix Flags" and "LLDP IPv6 Host Prefix Flags" under the "IANA OUI Ethernet Numbers" registry group. The allocation policy for these registries is "Expert Review" according to [RFC8126] with the guidance for Designated Experts being the same as for the LLDP TLV Subtypes registry in [RFC9542].¶
The initial allocations are as follows:¶
Bit Description Reference ----------------------------------------------------------------- 0 Anycast (A-Flag) This document 1-7 Unassigned
Bit Description Reference ----------------------------------------------------------------- 0 Anycast (A-Flag) This document 1-6 Unassigned 7 SRv6 Locator (L-Flag) This document
The extensions in this document MUST NOT be enabled by default. Implementations on both the host and router side MUST provide a per-port configuration option to enable this feature. The implementation on the router side SHOULD log the activity of prefix discovery for monitoring and troubleshooting purposes.¶
The extensions in this document introduce additional information in LLDP. The IEEE 802.1AE [MACsec] standard can be used for encryption and/or authentication to provide privacy and integrity. MACsec utilizes the Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for authenticated encryption and Galois Message Authentication Code (GMAC) if only authentication, but not encryption is required.¶
The MACsec Key Agreement (MKA) is included as part of the IEEE 802.1X-20200 Port-Based Network Access Control Standard [MKA]. The purpose of MKA is to provide a method for discovering MACsec peers and negotiating the security keys needed to secure the link.¶
A rogue host may inject arbitrary and invalid prefixes into its connected router that could result in diversion of traffic and disruption for applications and services. This feature is expected to be used in environments where the router and the hosts are secured and within a single administrative control - e.g., a DC.¶
The authors of this document would like to acknowledge the review and inputs provided by Ketan Talaulikar during the early stages of this work.¶