RFC 6361

PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol

📅 published August 2011, from ietf

🎀 RFC 6361 (the paperwork first, bestie)

RFC 6361 is titled PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol. It was written by J. Carlson (WorkingCode) and D. Eastlake 3rd (Huawei). It's a Standards Track document, ISSN 2070-1721, dated August 2011. The header doesn't list any RFCs it obsoletes or updates. 💖

✨ Abstract

Okay, the big idea! PPP already has a Link Control Protocol (LCP) and a way to negotiate multiprotocol traffic over point-to-point links. This doc adds PPP support for the TRILL Protocol, so RBridges (Routing Bridges) can talk directly to each other over PPP links. 🦋

Status of This Memo 🌸

This is an Internet Standards Track document. 💅

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741. 🧚

Current status info, errata, and feedback can be found at http://www.rfc-editor.org/info/rfc6361. 🔥

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, which you can find at http://trustee.ietf.org/license-info (as in effect on the publication date). Read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🫶

Table of Contents 📜

1. Introduction ....................................................2
2. PPP TRILL Negotiation ...........................................3
   2.1. TNCP Packet Format .........................................3
   2.2. TNP Packet Format ..........................................4
   2.3. TLSP Packet Format .........................................5
3. TRILL PPP Behavior ..............................................5
4. Security Considerations .........................................6
5. IANA Considerations .............................................6
6. References ......................................................7
   6.1. Normative References .......................................7
   6.2. Informative References .....................................7
7. Acknowledgements ................................................8

1. Introduction 🦋

Okay so the TRILL Protocol [RFC6325] is the set of mechanisms RBridges use to talk to each other. These devices can bridge together big 802 networks using link-state protocols, instead of the old-school spanning tree mechanisms [RFC5556]. It's giving modern. 💅

Over Ethernet, TRILL uses two separate Ethertypes. One carries encapsulation headers (the user data), and the other carries link-state messages, which work out the network topology using a protocol based on [IS-IS] [RFC6326]. These two protocols must be distinguished from one another, and kept separate from all other traffic. Bestie, boundaries matter. 🎀

Now, PPP [RFC1661] is often used to connect routers, especially over telecom links. In that setup it can be super useful to bridge between Ethernet segments across those PPP links and bring remote networks into an existing TRILL cloud. ☁️ The existing Bridging Control Protocol (BCP) [RFC3518] already lets you bridge Ethernet frames directly over PPP. But ngl, that mechanism is inefficient and not good enough for TRILL, which can be optimized for PPP links. 🙈

To connect these devices over PPP links, three protocol numbers are needed. They're reserved like this:

   Value (in hex)  Protocol Name
   --------------  -------------------------------------
    005d           TRILL Network Protocol (TNP)
    405d           TRILL Link State Protocol (TLSP)
    805d           TRILL Network Control Protocol (TNCP)

The next section goes through how these three protocols are used. 🧚

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]. Those capitalised words are the official BCP 14 vibes, so read them the [RFC2119] way. 📖

2. PPP TRILL Negotiation 🌸

The TRILL Network Control Protocol (TNCP) handles negotiating the use of the TRILL Network Protocol (TNP) and the TRILL Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism and state machine as LCP does (Section 4 of [RFC1661]). It's the same energy, different protocol. ✨

TNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any TNCP packets received when PPP is not in that phase MUST be silently ignored. Not in the phase? Not invited. 🙅‍♀️

The encapsulated network layer data (carried in TNP packets) and the topology information (carried in TLSP packets) MUST NOT be sent unless TNCP is in the Opened state. If a TNP or TLSP packet shows up while TNCP is not in the Opened state but LCP is in the Opened state, an implementation MUST silently discard the unexpected TNP or TLSP packet. Ghosting, denied. 👻

2.1. TNCP Packet Format 💖

Exactly one TNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805d (TNCP). Here's a summary of the TNCP packet format. The fields go 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 are used (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject). Every other code SHOULD result in a TNCP Code-Reject reply. 🙃

Identifier and Length: these work exactly as documented for LCP. Easy. 🧠

Data: this field's data is 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 of that is as described in [RFC1661]. 📚

Because no Configuration Options have been defined for TNCP yet, negotiating the use of the TRILL Protocol with IS-IS as the link state protocol is the default whenever no options are specified. A future document may specify Configuration Options to enable different TRILL operating modes, such as using a different link state protocol. Stay tuned, babes. 👀

2.2. 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 putting TRILL-encapsulated data in the PPP Information field. That data represents exactly one encapsulated packet. 📦

Here's the summary of this format:

    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"), with two swaps. The Outer MAC (Media Access Control) header and Ethertype get replaced by the PPP headers and Protocol Field, and the Ethernet Frame Check Sequence (FCS) isn't there. Both user data and End-Station Address Distribution Information (ESADI) packets are encoded this way. Consistency is serving. 💅

The PPP FCS follows the encapsulated data on links where the PPP FCS is in use. 🔐

Unlike TRILL Ethernet encapsulation, PPP nodes don't have MAC addresses, so there's no outer MAC. (High-Level Data Link Control (HDLC) addresses MAY be present in some situations, but that usage is outside the scope of this document.) No MAC, no problem. 🙌

2.3. 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 putting exactly one IS-IS Payload (Section 4.2.3 of [RFC6325], "TRILL IS-IS Frames") in the PPP Information field. ✨

Quick note: point-to-point IS-IS links only have an arbitrary circuit ID, and they don't use MAC addresses for identification. Ngl, that's a neat little difference. 🍓

3. TRILL PPP Behavior 💜

  1. On a PPP link, TRILL always uses point-to-point (P2P) Hellos. There's no need for TRILL-Hello frames, and per-port configuration isn't necessary either. P2P Hello messages, per "Point-to-Point IS to IS hello PDU" (Section 9.7 of [IS-IS]), don't use Neighbor IDs the same way they do 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. Handshake energy, always. 🤝
  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, there's no need to pass unencapsulated frames, because the link can't have any TRILL-ignorant peer to worry about. If the peer is not an RBridge, TNCP negotiation fails and TRILL is not used on the link. Only one, babe. Choose. 💅
  3. An implementation that has only PPP links might not have an Organizationally Unique Identifier (OUI) that can form an IS-IS System ID. Fixing that is outside the scope of this document. Still, it is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid System ID. For System ID uniqueness requirements, look at ISO/IEC 10589 [IS-IS]. Unique IDs are a whole vibe. 🌟
  4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of [RFC6325]) aren't needed on a PPP link. Implementations MUST NOT send MTU-probe messages, and they SHOULD NOT reply to these messages. Instead, the MTU computed by LCP SHOULD be used. Negotiating an LCP MTU of at least 1524, so there's room for an inner Ethernet payload of 1500 octets, is RECOMMENDED. Big MTU, big feelings. 🎀

4. Security Considerations 🔒

Okay bestie, security is where things get serious 🥺. 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. So those are your bodyguards 💪

Not every implementation needs specific security mechanisms at the PPP layer. For example, that's fine if they're designed to be deployed only where the networking environment is trusted, or where other layers provide adequate security 🌸 A complete list of possible deployment scenarios, threats, and options isn't possible, and it's outside the scope of this document. For applications involving sensitive data, you should always consider end-to-end security in addition to link security, so you get security in depth 🧱✨

Now, if you do need a PPP layer authentication mechanism 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 💖 And if you need more flexibility than CHAP gives you, the Extensible Authentication Protocol (EAP) [RFC3748] is a good alternative 🦋

If TRILL-over-PPP packets also need 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 runs over tunneling mechanisms, like the Layer Two Tunneling Protocol (L2TP) [RFC3931], tunnel security protocols may be available 🌈

For general TRILL protocol security considerations, see [RFC6325] 📖

5. IANA Considerations 🦋

IANA has assigned three PPP Protocol field values, 005d, 405d, and 805d, as described in Section 1 of this document. Slay 💅

IANA has also created a new "PPP TNCP Configuration Option Types" registry in the PPP-Numbers registry. It uses 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]. So hands off option 0 🙈

6. References 📚

6.1. 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.

6.2. 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.

7. 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. Iconic squad 👑

Authors' Addresses 🎀

James Carlson
WorkingCode
25 Essex Street
North Andover, MA 01845 USA

Phone: +1-781-301-2471
EMail: carlsonj@workingcode.com


Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
📦 where this page comes from