L3ND Upper-Layer Protocol ConfigurationArrcus & IIJ5147 Crystal SpringsBainbridge IslandWA98110USrandy@psg.comArrcus2077 Gateway Place, Suite #400San JoseCA95119United States of Americakeyur@arrcus.comThis document uses 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute List ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type and Payload Length are defined in apply to this PDU.As the ULPC PDU may contain keying material, e.g. , it SHOULD BE over TLS.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 L3DL PDU
Type registry as follows:
PDU
Code PDU Name
---- -------------------
9 ULPC
This document requests the IANA create a registry for L3DL ULPC
Type, which may range from 0 to 255. The name of the registry
should be L3DL-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 Rob Austein and Sue Hares.