502 lines
18 KiB
XML
502 lines
18 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="6"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-ulpc-06" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>L3ND Upper-Layer Protocol Configuration</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>Arrcus & IIJ</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>WA</region>
|
|
<code>98110</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Keyur Patel" initials="K." surname="Patel">
|
|
<organization>Arrcus</organization>
|
|
<address>
|
|
<postal>
|
|
<street>2077 Gateway Place, Suite #400</street>
|
|
<city>San Jose</city>
|
|
<region>CA</region>
|
|
<code>95119</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>keyur@arrcus.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>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.
|
|
</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
|
|
and only when, they appear in all capitals, as shown here.</t>
|
|
|
|
</note>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>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, <xref target="I-D.ymbk-idr-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.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="terminology" title="Reading and Terminology">
|
|
|
|
<t>The reader is assumed to have read Layer-3 Neighbor Discovery
|
|
<xref target="I-D.ymbk-idr-l3nd"/>. The terminology and PDUs there
|
|
are assumed here.</t>
|
|
|
|
<t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
|
|
assumed.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="ulps" title="Upper-Layer Protocol Configuration PDU">
|
|
|
|
<t>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:</t>
|
|
|
|
<!--
|
|
protocol "Version = 0:8,Type = 8:8,Payload Length:32,ULPC Type:8,AttrCount:8,Serial Number:32,Attribute Sub-TLV List ...:32"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 ... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>The Version, Type, and Payload Length as defined in <xref
|
|
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>As the ULPC PDU may contain keying material, e.g. <xref
|
|
target="RFC2385"/>, it SHOULD BE over TLS.</t>
|
|
|
|
<?rfc subcompact="yes"?>
|
|
<t>ULPC Type: A one byte integer denoting the type of the
|
|
upper-layer protocol
|
|
<list style="hanging" hangIndent="6">
|
|
<t hangText="0 :">Reserved</t>
|
|
<t hangText="1 :">BGP</t>
|
|
<t hangText="2-255 :">Reserved</t>
|
|
<?rfc subcompact="no"?></list></t>
|
|
|
|
<t>The one octet AttrCount is the number of attribute sub-TLVs in
|
|
the Attribute List.</t>
|
|
|
|
<t>The Attribute List is a, possibly null, set of sub-TLVs
|
|
describing the configuration attributes of the specific upper-layer
|
|
protocol.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<!--
|
|
protocol "Attr Type = 1:8,Attr Len:8,Payload:16"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
|
|
<section anchor="bgp" title="ULPC BGP Attribute sub-TLVs">
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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<!-- unless there is a BGP Restart Attribute
|
|
sub-TLV-->.</t>
|
|
|
|
<t>If there are one or more open BGP sessions, <!-- absent a BGP
|
|
Restart sub-TLV, --> receipt of a new BGP ULPC PDU SHOULD not
|
|
affect these sessions. The received data are stored for a future
|
|
session restart.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>If a peering address has been announced as a loopback, i.e.
|
|
MUST BE flagged as such in the L3ND Encapsulation PDU (see <xref
|
|
target="I-D.ymbk-idr-l3nd"/> 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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<!--
|
|
<section anchor="restart" title="BGP Restart">
|
|
|
|
<t>When all attributes in PDU have been processed, stop the
|
|
current BGP session and start a new one with the new attribute
|
|
set.</t>
|
|
|
|
<t>The four or 16 byte Dest IP tells both tha AFI and the IP
|
|
address of the BGP peer for the session to be restarted.</t>
|
|
|
|
<t>If there is no current BGP session to the specified peer,
|
|
start one.</t>
|
|
|
|
<!- -
|
|
protocol "Attr Type = 0:8,Attr Len = 4/16:8,Dest IP:128"
|
|
- ->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 = 0 |Attr Len = 4/16| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|
|
| |
|
|
+ +
|
|
| |
|
|
+ +
|
|
| Dest IP |
|
|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
</section>
|
|
-->
|
|
<section anchor="asn" title="BGP ASN">
|
|
|
|
<t>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.</t>
|
|
|
|
<!--
|
|
protocol "Attr Type = 1:8,Attr Len = 4:8,My ASN:32"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 ~
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
~ |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
<section anchor="bgpv4" title="BGP IPv4 Address">
|
|
|
|
<t>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.</t>
|
|
|
|
<t>As usual, the BGP OPEN capability negotiation will determine
|
|
the AFI/SAFIs to be transported over the peering, see <xref
|
|
target="RFC4760"/>.</t>
|
|
|
|
<!--
|
|
protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
<section anchor="bgpv6" title="BGP IPv6 Address">
|
|
|
|
<t>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.</t>
|
|
|
|
<t>As usual, the BGP OPEN capability negotiation will determine
|
|
the AFI/SAFIs to be transported over the peering, see <xref
|
|
target="RFC4760"/>.</t>
|
|
|
|
<!--
|
|
protocol "Attr Type = 3:8,Attr Len = 17:8,My IPv6 Peering Address:128,Prefix Len:8"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
<section anchor="bgpmd5" title="BGP Authentication sub-TLV">
|
|
|
|
<t>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 <xref target="RFC2385"/>), the name of a key chain in a
|
|
KARP database (see <xref target="RFC7210"/>), or one of multiple
|
|
Authentication sub-TLVs to support hop<xref
|
|
target="RFC4808"/>.</t>
|
|
|
|
<!--
|
|
protocol "Attr Type = 4:8,Attr Len:8,BGP Authentication Data ...:48"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 ... ~
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
<section anchor="bgpflags" title="BGP Miscellaneous Flags">
|
|
|
|
<t>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.</t>
|
|
<!--
|
|
protocol "Attr Type = 5:8,Attr Len = 2:8,Misc Flags:16"
|
|
-->
|
|
|
|
<figure>
|
|
<artwork>
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>Misc Flags:
|
|
<list style="hanging">
|
|
<?rfc subcompact="yes"?>
|
|
<t hangText="Bit 0: ">GTSM</t>
|
|
<t hangText="Bit 1: ">BFD</t>
|
|
<t hangText="Bit 2-15:">Must be zero</t>
|
|
<?rfc subcompact="no"?></list></t>
|
|
|
|
<t>The GTSM flag, when 1, indicates that the sender wishes to
|
|
enable the <xref target="RFC5082"/> Generalized TTL Security
|
|
Mechanism for the session.</t>
|
|
|
|
<t>The BFD flag, when 1, indicates that the sender wishes to
|
|
enable the <xref target="RFC5880"/> Bidirectional Forwarding
|
|
Detection for the session.</t>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>All the Security considerations of <xref
|
|
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
|
|
|
|
<t>As the ULPC PDU may contain keying material, see <xref
|
|
target="bgpmd5"/>, it SHOULD BE over TLS, not clear TCP.</t>
|
|
|
|
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>This document requests the IANA create a new entry in the L3ND PDU
|
|
Type registry as follows:</t>
|
|
<figure>
|
|
<artwork>
|
|
PDU
|
|
Code PDU Name
|
|
---- -------------------
|
|
9 ULPC
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>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 <xref target="RFC5226"/>, either standards track or
|
|
experimental. The initial entries should be the following:</t>
|
|
<figure>
|
|
<artwork>
|
|
Value Name
|
|
----- -------------------
|
|
0 Reserved
|
|
1 BGP
|
|
2-255 Reserved
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
<section anchor="acks" title="Acknowledgments">
|
|
|
|
<t>The authors thank Rob Austein, Sue Hares, and Russ Housley.</t>
|
|
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.2119.xml"?>
|
|
<?rfc include="reference.RFC.4271.xml"?>
|
|
<?rfc include="reference.RFC.4760.xml"?>
|
|
<?rfc include="reference.RFC.5082.xml"?>
|
|
<?rfc include="reference.RFC.5226.xml"?>
|
|
<?rfc include="reference.RFC.5880.xml"?>
|
|
<?rfc include="reference.RFC.8174.xml"?>
|
|
<?rfc include="reference.I-D.ymbk-idr-l3nd.xml"?>
|
|
</references>
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.2385.xml"?>
|
|
<?rfc include="reference.RFC.4808.xml"?>
|
|
<?rfc include="reference.RFC.7210.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
</rfc>
|