From eb49ad4287895e842e76f8fa0f25c9ae5390eee2 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 2 Feb 2026 18:11:50 -0800 Subject: [PATCH] -00 published --- draft-ymbk-lsvr-l3nd-ulpc.xml | 525 ++++++++++++++++++++++++++++++++++ 1 file changed, 525 insertions(+) create mode 100644 draft-ymbk-lsvr-l3nd-ulpc.xml diff --git a/draft-ymbk-lsvr-l3nd-ulpc.xml b/draft-ymbk-lsvr-l3nd-ulpc.xml new file mode 100644 index 0000000..9bc97d7 --- /dev/null +++ b/draft-ymbk-lsvr-l3nd-ulpc.xml @@ -0,0 +1,525 @@ + + + + + + + + + + + + + + + + + + L3ND Upper-Layer Protocol Configuration + + + Arrcus & IIJ +
+ + 5147 Crystal Springs + Bainbridge Island + WA + 98110 + US + + randy@psg.com +
+ + + + Arrcus, Inc +
+ sra@hactrn.net +
+ + + + Hickory Hill Consulting +
+ + 7453 Hickory Hill + Saline + MI + 48176 + USA + + +1-734-604-0332 + shares@ndzh.com +
+ + + + Arrcus +
+ + 2077 Gateway Place, Suite #400 + San Jose + CA + 95119 + United States of America + + keyur@arrcus.com +
+ + + + + + + This document adds PDUs to the Layer-3 Neighbor Discovery + protocol to communicate the parameters needed to exchange + inter-device Upper Layer Protocol Configuration for upper-layer + protocols such as the BGP family. + + + + + + + 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 when, + and only when, they appear in all capitals, as shown here. + + + + + + + +
+ + Massive Data Centers (MDCs) which use upper-layer protocols such + as BGP4 and other routing protocols may use the Layer-3 Neighbor + Discovery Protocol, L3ND, to + reveal the inter-device links of the topology. It is desirable for + devices to facilitate the configuration parameters of those upper + layer protocols to enable more hands-free configuration. This + document defines a new L3ND PDU to communicate these Upper-Layer + Protocol Configuration parameters. + +
+ +
+ + The reader is assumed to have read Layer-3 Neighbor Discovery + . The terminology and PDUs there + are assumed here. + + Familiarity with the BGP4 Protocol is + assumed. + +
+ +
+ + To communicate parameters required to configure peering and + operation of Upper-Layer Protocols at IP layer-3 and above, e.g., + BGP sessions on a link, a neutral sub-TLV based Upper-Layer Protocol + PDU is defined 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Version = 0 | Type = 8 | Payload Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | ULPC Type | AttrCount | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Serial Number | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attribute List ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + The Version, Type, and Payload Length as defined in apply to this PDU. + + The BGP Authentication sub-TLV provides for provisioning MD5, + which is a quite weak hash, horribly out of fashion, and kills + puppies. But, like it or not, it has been sufficient against the + kinds of attacks BGP TCP sessions have endured. So it is what BGP + deployments use. + + As the ULPC PDU may contain keying material, e.g. , it SHOULD BE over TLS. + + + ULPC Type: A one byte integer denoting the type of the + upper-layer protocol + + Reserved + BGP + Reserved + + + The one octet AttrCount is the number of attribute sub-TLVs in + the Attribute List. + + The Attribute List is a, possibly null, set of sub-TLVs + describing the configuration attributes of the specific upper-layer + protocol. + + An Attribute consists of a one octet Attribute Type, a one octet + Attribute Length of the number of octets in the Attribute, and a + Payload of arbitrary length up to 253 octets. + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len | Payload | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + +
+ + The parameters needed for BGP peering on a link are exchanged + in sub-TLVs within an Upper-Layer Protocol PDU. The following + describe the various sub-TLVs for BGP. + + The goal is to provide the minimal set of configuration + parameters needed by BGP OPEN to successfully start a BGP peering. + The goal is specifically not to replace or conflict with data + exchanged during BGP OPEN. Multiple sources of truth are a recipe + for complexity and hence pain. + + If there are multiple BGP sessions on a link, e.g., IPv4 and + IPv6, then separate BGP ULPC PDUs should be sent, one for each + address family. + + A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU + for an particular address family on a specific link at any point + in time; receipt of a new BGP ULPC PDU for a particular address + family replaces the data any previous one; but does not actually + affect the session. + + If there are one or more open BGP sessions, receipt of a new BGP ULPC PDU SHOULD not + affect these sessions. The received data are stored for a future + session restart. + + As a link may have multiple encapsulations and multiple + addresses for an IP encapsulation, which address of which + encapsulation is to be used for the BGP session MUST be + specified. + + For each BGP peering on a link here MUST be one agreed + encapsulation, and the addresses used MUST be in the corresponding + L3ND IPv4/IPv6 Encapsulation PDUs. If the choice is ambiguous, an + Attribute may be used to signal preferences. + + If a peering address has been announced as a loopback, i.e. + MUST BE flagged as such in the L3ND Encapsulation PDU (see Sec. 10.2), a two or three hop BGP + session MUST be established as needed. Otherwise a direct one hop + session is used. The BGP session to a loopback will forward to + the peer's address which was marked as Primary in the L3ND + Encapsulation Flags, iff it is in a subnet which is shared with + both BGP speakers. If the primary is not in a common subnet, then + the BGP speaker MAY pick a forwarding next hop that is in a subnet + they share. If there are multiple choices, the BGP speaker SHOULD + have signaled which subnet to choose in an Upper-Layer Protocol + Configuration PDU Attribute. + + Attributes MUST be unique in the Attribute List. I.e. a + particular Attr Type MUST NOT occur more than once in the + Attribute List. If a ULPC PDU is received with more than one + occurrence of a particular Attr Type, an Error ACK MUST be + returned. + + As there are separate PDU Attr Types for IPv4 and IPv6 peering + addresses, separate sessions for the two AFIs MAY be created for + the same ASN in one ULPC PDU. + + +
+ + The four octet Autonomous System number MUST be specified. + If the AS Number is less than 32 bits, it is padded with high + order zeros. + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len = 4 | My ASN ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP IPv4 Address sub-TLV announces the sender's four octet + IPv4 BGP peering source address and one octet Prefix Lenth to be + used by the receiver. At least one of IPv4 or IPv6 BGP source + addresses MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 2 | Attr Len = 5 | My IPv4 Peering Address ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP IPv6 Address sub-TLV announces the sender's 16 octet + IPv6 BGP peering source address and one octet Prefix Length to + be used by the receiver. At least one of IPv4 or IPv6 BGP + source addresses MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 3 | Attr Len = 17 | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | ++ + +| My IPv6 Peering Address | ++ + +| | ++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP Authentication sub-TLV provides any authentication + data needed to OPEN the BGP session. Depending on operator + configuration of the environment, it might be a simple MD5 key + (see ), the name of a key chain in a + KARP database (see ), or one of multiple + Authentication sub-TLVs to support hop. + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 4 | Attr Len | ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +~ BGP Authentication Data ... ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP session OPEN has extensive, and a bit complex, + capability negotiation facilities. In case one or more extra + attributes might be needed, the two octet BGP Miscellaneous + Flags sub-TLV may be used. + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 5 | Attr Len = 2 | Misc Flags | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + Misc Flags: + + + GTSM + BFD + Must be zero + + + The GTSM flag, when 1, indicates that the sender wishes to + enable the Generalized TTL Security + Mechanism for the session. + + The BFD flag, when 1, indicates that the sender wishes to + enable the Bidirectional Forwarding + Detection for the session. + +
+ +
+ +
+ +
+ + All the Security considerations of apply to this PDU. + + As the ULPC PDU may contain keying material, see , it SHOULD BE over TLS, not clear TCP. + + Any keying material in the PDU SHOULD BE salted and hashed. + + The BGP Authentication sub-TLV provides for provisioning MD5, + which is a quite weak hash, horribly out of fashion, and kills + puppies. But, like it or not, it has been sufficient against the + kinds of attacks BGP TCP sessions have endured. So it is what BGP + deployments use. + +
+ +
+ + This document requests the IANA create a new entry in the L3ND PDU + Type registry as follows: +
+ + PDU + Code PDU Name + ---- ------------------- + 9 ULPC + +
+ + This document requests the IANA create a registry for L3ND ULPC + Type, which may range from 0 to 255. The name of the registry + should be L3ND-ULPC-Type. The policy for adding to the registry is + RFC Required per , either standards track or + experimental. The initial entries should be the following: +
+ + Value Name + ----- ------------------- + 0 Reserved + 1 BGP + 2-255 Reserved + +
+ +
+ +
+ + The authors thank Russ Housley. + +
+ + + + + + + + + + + + + + + + + + + + + + + +