Difference between revisions of "RFC6361"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) J. Carlson Request for Comments: 6361 WorkingCode Category: Standards Tra...") |
|||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Internet Engineering Task Force (IETF) J. Carlson | Internet Engineering Task Force (IETF) J. Carlson | ||
Request for Comments: 6361 WorkingCode | Request for Comments: 6361 WorkingCode | ||
Line 10: | Line 4: | ||
ISSN: 2070-1721 Huawei | ISSN: 2070-1721 Huawei | ||
August 2011 | August 2011 | ||
− | |||
PPP Transparent Interconnection of Lots of Links (TRILL) Protocol | PPP Transparent Interconnection of Lots of Links (TRILL) Protocol | ||
Control Protocol | Control Protocol | ||
− | Abstract | + | '''Abstract''' |
The Point-to-Point Protocol (PPP) defines a Link Control Protocol | The Point-to-Point Protocol (PPP) defines a Link Control Protocol | ||
Line 24: | Line 17: | ||
PPP links. | PPP links. | ||
− | Status of This Memo | + | '''Status of This Memo''' |
This is an Internet Standards Track document. | This is an Internet Standards Track document. | ||
Line 38: | Line 31: | ||
http://www.rfc-editor.org/info/rfc6361. | http://www.rfc-editor.org/info/rfc6361. | ||
− | Copyright Notice | + | '''Copyright Notice''' |
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | ||
Line 52: | Line 45: | ||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | ||
described in the Simplified BSD License. | described in the Simplified BSD License. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== Introduction == | == Introduction == | ||
− | The TRILL Protocol [RFC6325] defines a set of mechanisms used to | + | The TRILL Protocol [[RFC6325]] defines a set of mechanisms used to |
communicate between RBridges. These devices can bridge together | communicate between RBridges. These devices can bridge together | ||
large 802 networks using link-state protocols in place of the | large 802 networks using link-state protocols in place of the | ||
− | traditional spanning tree mechanisms [RFC5556]. | + | traditional spanning tree mechanisms [[RFC5556]]. |
Over Ethernet, TRILL uses two separate Ethertypes to distinguish | Over Ethernet, TRILL uses two separate Ethertypes to distinguish | ||
between encapsulation headers, which carry user data, and link-state | between encapsulation headers, which carry user data, and link-state | ||
messages, which compute network topology using a protocol based on | messages, which compute network topology using a protocol based on | ||
− | [IS-IS] [RFC6326]. These two protocols must be distinguished from | + | [IS-IS] [[RFC6326]]. These two protocols must be distinguished from |
one another, and segregated from all other traffic. | one another, and segregated from all other traffic. | ||
− | In a network where PPP [RFC1661] is used to interconnect routers | + | In a network where PPP [[RFC1661]] is used to interconnect routers |
(often over telecommunications links), it may be advantageous to be | (often over telecommunications links), it may be advantageous to be | ||
able to bridge between Ethernet segments over those PPP links, and | able to bridge between Ethernet segments over those PPP links, and | ||
thus integrate remote networks with an existing TRILL cloud. The | thus integrate remote networks with an existing TRILL cloud. The | ||
− | existing Bridging Control Protocol (BCP) [RFC3518] allows direct | + | existing Bridging Control Protocol (BCP) [[RFC3518]] allows direct |
bridging of Ethernet frames over PPP. However, this mechanism is | bridging of Ethernet frames over PPP. However, this mechanism is | ||
inefficient and inadequate for TRILL, which can be optimized for use | inefficient and inadequate for TRILL, which can be optimized for use | ||
Line 91: | Line 79: | ||
The usage of these three protocols is described in detail in the | The usage of these three protocols is described in detail in the | ||
following section. | following section. | ||
− | |||
− | |||
− | |||
− | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in [RFC2119]. | + | document are to be interpreted as described in [[RFC2119]]. |
== PPP TRILL Negotiation == | == PPP TRILL Negotiation == | ||
Line 106: | Line 90: | ||
Link State Protocol (TLSP) on a PPP link. TNCP uses the same option | Link State Protocol (TLSP) on a PPP link. TNCP uses the same option | ||
negotiation mechanism and state machine as described for LCP | negotiation mechanism and state machine as described for LCP | ||
− | (Section 4 of [RFC1661]). | + | (Section 4 of [[RFC1661]]). |
TNCP packets MUST NOT be exchanged until PPP has reached the Network- | TNCP packets MUST NOT be exchanged until PPP has reached the Network- | ||
Line 144: | Line 128: | ||
These are as documented for LCP. | These are as documented for LCP. | ||
− | |||
− | |||
− | |||
− | |||
Data | Data | ||
This field contains data formatted as described in Section 5 of | This field contains data formatted as described in Section 5 of | ||
− | [RFC1661]. Codes 1-4 use Type-Length-Data sequences, Codes 5 | + | [[RFC1661]]. Codes 1-4 use Type-Length-Data sequences, Codes 5 |
and 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, | and 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, | ||
− | all as described in [RFC1661]. | + | all as described in [[RFC1661]]. |
Because no Configuration Options have been defined for TNCP, | Because no Configuration Options have been defined for TNCP, | ||
Line 181: | Line 161: | ||
This is identical to the TRILL Ethernet format (Section 4.1 of | This is identical to the TRILL Ethernet format (Section 4.1 of | ||
− | [RFC6325], "Ethernet Data Encapsulation"), except that the Outer MAC | + | [[RFC6325]], "Ethernet Data Encapsulation"), except that the Outer MAC |
(Media Access Control) header and Ethertype are replaced by the PPP | (Media Access Control) header and Ethertype are replaced by the PPP | ||
headers and Protocol Field, and the Ethernet Frame Check Sequence | headers and Protocol Field, and the Ethernet Frame Check Sequence | ||
Line 194: | Line 174: | ||
(HDLC) addresses MAY be present in some situations; such usage is | (HDLC) addresses MAY be present in some situations; such usage is | ||
outside the scope of this document.) | outside the scope of this document.) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== TLSP Packet Format === | === TLSP Packet Format === | ||
Line 206: | Line 179: | ||
When TNCP is in the Opened state, TLSP packets are sent by setting | When TNCP is in the Opened state, TLSP packets are sent by setting | ||
the PPP Protocol field to hex 405d (TLSP) and placing exactly one | the PPP Protocol field to hex 405d (TLSP) and placing exactly one | ||
− | IS-IS Payload (Section 4.2.3 of [RFC6325], "TRILL IS-IS Frames") in | + | IS-IS Payload (Section 4.2.3 of [[RFC6325]], "TRILL IS-IS Frames") in |
the PPP Information field. | the PPP Information field. | ||
Line 219: | Line 192: | ||
IS to IS hello PDU" (Section 9.7 of [IS-IS]), do not use Neighbor | IS to IS hello PDU" (Section 9.7 of [IS-IS]), do not use Neighbor | ||
IDs in the same manner as on Ethernet. However, per | IDs in the same manner as on Ethernet. However, per | ||
− | Section 4.2.4.1 of [RFC6325], the three-way IS-IS handshake using | + | Section 4.2.4.1 of [[RFC6325]], the three-way IS-IS handshake using |
extended circuit IDs is required on point-to-point links, such | extended circuit IDs is required on point-to-point links, such | ||
as PPP. | as PPP. | ||
2. RBridges are never appointed forwarders on PPP links. If an | 2. RBridges are never appointed forwarders on PPP links. If an | ||
− | implementation includes BCP [RFC3518], then it MUST ensure that | + | implementation includes BCP [[RFC3518]], then it MUST ensure that |
only one of BCP or TNCP is negotiated on a link, and not both. If | only one of BCP or TNCP is negotiated on a link, and not both. If | ||
the peer is an RBridge, then there is no need to pass | the peer is an RBridge, then there is no need to pass | ||
Line 240: | Line 213: | ||
4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of | 4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of | ||
− | [RFC6325]) are not needed on a PPP link. Implementations MUST NOT | + | [[RFC6325]]) are not needed on a PPP link. Implementations MUST NOT |
send MTU-probe messages and SHOULD NOT reply to these messages. | send MTU-probe messages and SHOULD NOT reply to these messages. | ||
The MTU computed by LCP SHOULD be used instead. Negotiating an | The MTU computed by LCP SHOULD be used instead. Negotiating an | ||
LCP MTU of at least 1524, to allow for an inner Ethernet payload | LCP MTU of at least 1524, to allow for an inner Ethernet payload | ||
of 1500 octets, is RECOMMENDED. | of 1500 octets, is RECOMMENDED. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Security Considerations == | == Security Considerations == | ||
Line 259: | Line 223: | ||
Existing PPP and IS-IS security mechanisms may play important roles | Existing PPP and IS-IS security mechanisms may play important roles | ||
in a network of RBridges interconnected by PPP links. At the TRILL | in a network of RBridges interconnected by PPP links. At the TRILL | ||
− | IS-IS layer, the IS-IS authentication mechanism [RFC5304] [RFC5310] | + | IS-IS layer, the IS-IS authentication mechanism [[RFC5304]] [[RFC5310]] |
prevents fabrication of link-state control messages. | prevents fabrication of link-state control messages. | ||
Line 275: | Line 239: | ||
protect the establishment of a link and identify a link with a known | protect the establishment of a link and identify a link with a known | ||
peer, implementation of the PPP Challenge Handshake Authentication | peer, implementation of the PPP Challenge Handshake Authentication | ||
− | Protocol (CHAP) [RFC1994] is RECOMMENDED. Should greater flexibility | + | Protocol (CHAP) [[RFC1994]] is RECOMMENDED. Should greater flexibility |
than that provided by CHAP be required, the Extensible Authentication | than that provided by CHAP be required, the Extensible Authentication | ||
− | Protocol (EAP) [RFC3748] is a good alternative. | + | Protocol (EAP) [[RFC3748]] is a good alternative. |
If TRILL-over-PPP packets also require confidentiality, the PPP | If TRILL-over-PPP packets also require confidentiality, the PPP | ||
Encryption Control Protocol (ECP) link encryption mechanisms | Encryption Control Protocol (ECP) link encryption mechanisms | ||
− | [RFC1968] can protect the confidentiality and integrity of all | + | [[RFC1968]] can protect the confidentiality and integrity of all |
packets on the PPP link. | packets on the PPP link. | ||
And when PPP is run over tunneling mechanisms, such as the Layer Two | And when PPP is run over tunneling mechanisms, such as the Layer Two | ||
− | Tunneling Protocol (L2TP) [RFC3931], tunnel security protocols may be | + | Tunneling Protocol (L2TP) [[RFC3931]], tunnel security protocols may be |
available. | available. | ||
− | For general TRILL protocol security considerations, see [RFC6325]. | + | For general TRILL protocol security considerations, see [[RFC6325]]. |
== IANA Considerations == | == IANA Considerations == | ||
Line 301: | Line 265: | ||
All TNCP Configuration Option Types except 0 are "Unassigned" and | All TNCP Configuration Option Types except 0 are "Unassigned" and | ||
available for future use, based on "IETF Review", as described in | available for future use, based on "IETF Review", as described in | ||
− | [[BCP26|BCP 26]] [RFC5226]. Option 0 is allocated for use with Vendor-Specific | + | [[BCP26|BCP 26]] [[RFC5226]]. Option 0 is allocated for use with Vendor-Specific |
− | Options, as described in [RFC2153]. | + | Options, as described in [[RFC2153]]. |
+ | == References == | ||
+ | === Normative References === | ||
+ | [[RFC1661]] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", | ||
+ | [[STD51|STD 51]], [[RFC1661|RFC 1661]], July 1994. | ||
+ | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | ||
+ | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. | ||
− | + | [[RFC5226]] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |
+ | IANA Considerations Section in RFCs", [[BCP26|BCP 26]], [[RFC5226|RFC 5226]], | ||
+ | May 2008. | ||
− | + | [[RFC6325]] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. | |
+ | Ghanwani, "Routing Bridges (RBridges): Base Protocol | ||
+ | Specification", [[RFC6325|RFC 6325]], July 2011. | ||
− | |||
− | |||
− | |||
− | |||
=== Informative References === | === Informative References === | ||
− | [IS-IS] International Organization for Standardization, | + | [IS-IS] International Organization for Standardization, |
− | [RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", | + | "Intermediate system to Intermediate system intra-domain |
− | [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication | + | routeing information exchange protocol for use in |
− | [RFC2153] Simpson, W., "PPP Vendor Extensions", [[RFC2153|RFC 2153]], May 1997. | + | conjunction with the protocol for providing the |
− | [RFC3518] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point | + | connectionless-mode Network Service (ISO 8473)", ISO/IEC |
− | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | + | 10589:2002, Second Edition, November 2002. |
− | + | ||
+ | [[RFC1968]] Meyer, G., "The PPP Encryption Control Protocol (ECP)", | ||
+ | [[RFC1968|RFC 1968]], June 1996. | ||
+ | |||
+ | [[RFC1994]] Simpson, W., "PPP Challenge Handshake Authentication | ||
+ | Protocol (CHAP)", [[RFC1994|RFC 1994]], August 1996. | ||
+ | |||
+ | [[RFC2153]] Simpson, W., "PPP Vendor Extensions", [[RFC2153|RFC 2153]], May 1997. | ||
+ | |||
+ | [[RFC3518]] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point | ||
+ | Protocol (PPP) Bridging Control Protocol (BCP)", | ||
+ | [[RFC3518|RFC 3518]], April 2003. | ||
+ | |||
+ | [[RFC3748]] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | ||
+ | Levkowetz, Ed., "Extensible Authentication Protocol | ||
+ | (EAP)", [[RFC3748|RFC 3748]], June 2004. | ||
+ | [[RFC3931]] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., | ||
+ | "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", | ||
+ | [[RFC3931|RFC 3931]], March 2005. | ||
+ | [[RFC5304]] Li, T. and R. Atkinson, "IS-IS Cryptographic | ||
+ | Authentication", [[RFC5304|RFC 5304]], October 2008. | ||
+ | [[RFC5310]] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | ||
+ | and M. Fanto, "IS-IS Generic Cryptographic | ||
+ | Authentication", [[RFC5310|RFC 5310]], February 2009. | ||
+ | [[RFC5556]] Touch, J. and R. Perlman, "Transparent Interconnection of | ||
+ | Lots of Links (TRILL): Problem and Applicability | ||
+ | Statement", [[RFC5556|RFC 5556]], May 2009. | ||
+ | [[RFC6326]] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. | ||
+ | Ghanwani, "Transparent Interconnection of Lots of Links | ||
+ | (TRILL) Use of IS-IS", [[RFC6326|RFC 6326]], July 2011. | ||
− | |||
− | |||
− | |||
− | |||
== Acknowledgements == | == Acknowledgements == | ||
Line 350: | Line 345: | ||
Phone: +1-781-301-2471 | Phone: +1-781-301-2471 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | ||
Line 359: | Line 353: | ||
Phone: +1-508-333-2270 | Phone: +1-508-333-2270 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Standards Track]] | [[Category:Standards Track]] |
Latest revision as of 10:25, 1 October 2020
Internet Engineering Task Force (IETF) J. Carlson Request for Comments: 6361 WorkingCode Category: Standards Track D. Eastlake 3rd ISSN: 2070-1721 Huawei
August 2011
PPP Transparent Interconnection of Lots of Links (TRILL) Protocol
Control Protocol
Abstract
The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6361.
Copyright Notice
Copyright (c) 2011 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Contents
Introduction
The TRILL Protocol RFC6325 defines a set of mechanisms used to communicate between RBridges. These devices can bridge together large 802 networks using link-state protocols in place of the traditional spanning tree mechanisms RFC5556.
Over Ethernet, TRILL uses two separate Ethertypes to distinguish between encapsulation headers, which carry user data, and link-state messages, which compute network topology using a protocol based on [IS-IS] RFC6326. These two protocols must be distinguished from one another, and segregated from all other traffic.
In a network where PPP RFC1661 is used to interconnect routers (often over telecommunications links), it may be advantageous to be able to bridge between Ethernet segments over those PPP links, and thus integrate remote networks with an existing TRILL cloud. The existing Bridging Control Protocol (BCP) RFC3518 allows direct bridging of Ethernet frames over PPP. However, this mechanism is inefficient and inadequate for TRILL, which can be optimized for use over PPP links.
To interconnect these devices over PPP links, three protocol numbers are needed, and are reserved as follows:
Value (in hex) Protocol Name -------------- ------------------------------------- 005d TRILL Network Protocol (TNP) 405d TRILL Link State Protocol (TLSP) 805d TRILL Network Control Protocol (TNCP)
The usage of these three protocols is described in detail in the following section.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
PPP TRILL Negotiation
The TRILL Network Control Protocol (TNCP) is responsible for negotiating the use of the TRILL Network Protocol (TNP) and TRILL Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism and state machine as described for LCP (Section 4 of RFC1661).
TNCP packets MUST NOT be exchanged until PPP has reached the Network- Layer Protocol phase. Any TNCP packets received when not in that phase MUST be silently ignored.
The encapsulated network layer data, carried in TNP packets, and topology information, carried in TLSP packets, MUST NOT be sent unless TNCP is in the Opened state. If a TNP or TLSP packet is received when TNCP is not in the Opened state and LCP is in the Opened state, an implementation MUST silently discard the unexpected TNP or TLSP packet.
TNCP Packet Format
Exactly one TNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805d (TNCP). A summary of the TNCP packet format is shown below. The fields are transmitted from left to right.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+
Code
Only LCP Code values 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a TNCP Code-Reject reply.
Identifier and Length
These are as documented for LCP.
Data
This field contains data formatted as described in Section 5 of RFC1661. Codes 1-4 use Type-Length-Data sequences, Codes 5 and 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, all as described in RFC1661.
Because no Configuration Options have been defined for TNCP, negotiating the use of the TRILL Protocol with IS-IS for the link state protocol is the default when no options are specified. A future document may specify the use of Configuration Options to enable different TRILL operating modes, such as the use of a different link state protocol.
TNP Packet Format
When TNCP is in the Opened state, TNP packets are sent by setting the PPP Protocol field to hex 005d (TNP) and placing TRILL-encapsulated data representing exactly one encapsulated packet in the PPP Information field.
A summary of this format is provided 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress (RB1) Nickname | Inner Destination MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This is identical to the TRILL Ethernet format (Section 4.1 of RFC6325, "Ethernet Data Encapsulation"), except that the Outer MAC (Media Access Control) header and Ethertype are replaced by the PPP headers and Protocol Field, and the Ethernet Frame Check Sequence (FCS) is not present. Both user data and End-Station Address Distribution Information (ESADI) packets are encoded in this format.
The PPP FCS follows the encapsulated data on links where the PPP FCS is in use.
Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC addresses, so no outer MAC is present. (High-Level Data Link Control (HDLC) addresses MAY be present in some situations; such usage is outside the scope of this document.)
TLSP Packet Format
When TNCP is in the Opened state, TLSP packets are sent by setting the PPP Protocol field to hex 405d (TLSP) and placing exactly one IS-IS Payload (Section 4.2.3 of RFC6325, "TRILL IS-IS Frames") in the PPP Information field.
Note that point-to-point IS-IS links have only an arbitrary circuit ID, and do not use MAC addresses for identification.
TRILL PPP Behavior
1. On a PPP link, TRILL always uses point-to-point (P2P) Hellos.
There is no need for TRILL-Hello frames, nor is per-port configuration necessary. P2P Hello messages, per "Point-to-Point IS to IS hello PDU" (Section 9.7 of [IS-IS]), do not use Neighbor IDs in the same manner as on Ethernet. However, per Section 4.2.4.1 of RFC6325, the three-way IS-IS handshake using extended circuit IDs is required on point-to-point links, such as PPP.
2. RBridges are never appointed forwarders on PPP links. If an
implementation includes BCP RFC3518, then it MUST ensure that only one of BCP or TNCP is negotiated on a link, and not both. If the peer is an RBridge, then there is no need to pass unencapsulated frames, as the link can have no TRILL-ignorant peer to be concerned about. If the peer is not an RBridge, then TNCP negotiation fails and TRILL is not used on the link.
3. An implementation that has only PPP links might have no
Organizationally Unique Identifier (OUI) that can form an IS-IS System ID. Resolving that issue is outside the scope of this document; however, it is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid System ID. Refer to ISO/IEC 10589 [IS-IS] regarding System ID uniqueness requirements.
4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of
RFC6325) are not needed on a PPP link. Implementations MUST NOT send MTU-probe messages and SHOULD NOT reply to these messages. The MTU computed by LCP SHOULD be used instead. Negotiating an LCP MTU of at least 1524, to allow for an inner Ethernet payload of 1500 octets, is RECOMMENDED.
Security Considerations
Existing PPP and IS-IS security mechanisms may play important roles in a network of RBridges interconnected by PPP links. At the TRILL IS-IS layer, the IS-IS authentication mechanism RFC5304 RFC5310 prevents fabrication of link-state control messages.
Not all implementations need to include specific security mechanisms at the PPP layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document. For applications involving sensitive data, end-to-end security should always be considered in addition to link security to provide security in depth.
However, in case a PPP layer authentication mechanism is needed to protect the establishment of a link and identify a link with a known peer, implementation of the PPP Challenge Handshake Authentication Protocol (CHAP) RFC1994 is RECOMMENDED. Should greater flexibility than that provided by CHAP be required, the Extensible Authentication Protocol (EAP) RFC3748 is a good alternative.
If TRILL-over-PPP packets also require confidentiality, the PPP Encryption Control Protocol (ECP) link encryption mechanisms RFC1968 can protect the confidentiality and integrity of all packets on the PPP link.
And when PPP is run over tunneling mechanisms, such as the Layer Two Tunneling Protocol (L2TP) RFC3931, tunnel security protocols may be available.
For general TRILL protocol security considerations, see RFC6325.
IANA Considerations
IANA has assigned three PPP Protocol field values, 005d, 405d, and 805d, as described in Section 1 of this document.
IANA has created a new "PPP TNCP Configuration Option Types" registry in the PPP-Numbers registry, using the same format as the existing "PPP LCP Configuration Option Types" registry.
All TNCP Configuration Option Types except 0 are "Unassigned" and available for future use, based on "IETF Review", as described in BCP 26 RFC5226. Option 0 is allocated for use with Vendor-Specific Options, as described in RFC2153.
References
Normative References
RFC1661 Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC5226 Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
RFC6325 Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
Informative References
[IS-IS] International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
RFC1968 Meyer, G., "The PPP Encryption Control Protocol (ECP)",
RFC 1968, June 1996.
RFC1994 Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
RFC2153 Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
RFC3518 Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point
Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
RFC3748 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
RFC3931 Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
RFC5304 Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
RFC5310 Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
RFC5556 Touch, J. and R. Perlman, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
RFC6326 Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
Acknowledgements
The authors thank Jari Arkko, Stewart Bryant, Ralph Droms, Linda Dunbar, Adrian Farrel, Stephen Farrell, Radia Perlman, Mike Shand, and William A. Simpson for their comments and help.
Authors' Addresses
James Carlson WorkingCode 25 Essex Street North Andover, MA 01845 USA
Phone: +1-781-301-2471 EMail: [email protected]
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Phone: +1-508-333-2270 EMail: [email protected]