diff --git a/Makefile b/Makefile index 6e31dae..9267d41 100644 --- a/Makefile +++ b/Makefile @@ -4,12 +4,12 @@ # # Your nroff document is called foo.txt. Change below as appropiate. -NAME=draft-ymbk-lsvr-l3nd-ulpc +NAME=draft-ymbk-idr-l3nd-ulpc DEST=psg.com:public_html RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete all: $(NAME).xml - xml2rfc $(NAME).xml --text + xml2rfc $(NAME).xml --html --text rsy: $(RSY) $(NAME).html $(DEST) diff --git a/draft-ymbk-lsvr-l3nd-ulpc.xml b/draft-ymbk-lsvr-l3nd-ulpc.xml deleted file mode 100644 index 053095d..0000000 --- a/draft-ymbk-lsvr-l3nd-ulpc.xml +++ /dev/null @@ -1,525 +0,0 @@ - - - - - - - - - - - - - - - - - - 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. - -
- - - - - - - - - - - - - - - - - - - - - - - -