The determination as to whether a vendor-private message is understood is based on the Type and the mandatory Vendor ID field. Implementations that support vendor-private TLVs MUST support a user-accessible configuration interface that causes the U-bit to be set on all transmitted vendor-private TLVs; this requirement MAY be satisfied by a user-accessible configuration interface that prevents transmission of all vendor-private TLVs for which the U- bit is clear. F-bit Forward unknown TLV bit. This bit only applies when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message. Type Type value in the range 0x3E00 through 0x3EFF. Together, the Type and Vendor ID field specify how the Data field is to be interpreted. Length Specifies the cumulative length in octets of the Vendor ID and Data fields. Vendor ID 802 Vendor ID as assigned by the IEEE. Data The remaining octets after the Vendor ID in the Value field are optional vendor-dependent data.
Message Length Specifies the cumulative length in octets of the Message ID, Vendor ID, Remaining Mandatory Parameters, and Optional Parameters. Message ID 32-bit integer used to identify this message. Used by the sending LSR to facilitate identifying Notification messages that may apply to this message. An LSR sending a Notification message in response to this message will include this Message ID in the notification message; see Section "Notification Message". Vendor ID 802 Vendor ID as assigned by the IEEE. Remaining Mandatory Parameters Variable length set of remaining required message parameters. Optional Parameters Variable length set of optional message parameters.
Message Name Type Section Title Notification 0x0001 "Notification Message" Hello 0x0100 "Hello Message" Initialization 0x0200 "Initialization Message" KeepAlive 0x0201 "KeepAlive Message" Address 0x0300 "Address Message" Address Withdraw 0x0301 "Address Withdraw Message" Label Mapping 0x0400 "Label Mapping Message" Label Request 0x0401 "Label Request Message" Label Withdraw 0x0402 "Label Withdraw Message" Label Release 0x0403 "Label Release Message" Label Abort Request 0x0404 "Label Abort Request Message" Vendor-Private 0x3E00- "LDP Vendor-Private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF "FEC TLV" Address List 0x0101 "Address List TLV" Hop Count 0x0103 "Hop Count TLV" Path Vector 0x0104 "Path Vector TLV" Generic Label 0x0200 "Generic Label TLV" ATM Label 0x0201 "ATM Label TLV" Frame Relay Label 0x0202 "Frame Relay Label TLV" Status 0x0300 "Status TLV" Extended Status 0x0301 "Notification Message" Returned PDU 0x0302 "Notification Message" Returned Message 0x0303 "Notification Message" Common Hello 0x0400 "Hello Message" Parameters IPv4 Transport Address 0x0401 "Hello Message" Configuration 0x0402 "Hello Message" Sequence Number IPv6 Transport Address 0x0403 "Hello Message" Common Session 0x0500 "Initialization Message" Parameters ATM Session Parameters 0x0501 "Initialization Message" Frame Relay Session 0x0502 "Initialization Message" Parameters Label Request 0x0600 "Label Mapping Message" Message ID
Vendor-Private 0x3E00- "LDP Vendor-Private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF "Status TLV" Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." Bad Protocol Version 1 0x00000002 "Events Signaled by ..." Bad PDU Length 1 0x00000003 "Events Signaled by ..." Unknown Message Type 0 0x00000004 "Events Signaled by ..." Bad Message Length 1 0x00000005 "Events Signaled by ..." Unknown TLV 0 0x00000006 "Events Signaled by ..." Bad TLV Length 1 0x00000007 "Events Signaled by ..." Malformed TLV Value 1 0x00000008 "Events Signaled by ..." Hold Timer Expired 1 0x00000009 "Events Signaled by ..." Shutdown 1 0x0000000A "Events Signaled by ..." Loop Detected 0 0x0000000B "Loop Detection" Unknown FEC 0 0x0000000C "FEC Procedures" No Route 0 0x0000000D "Label Request Mess ..." No Label Resources 0 0x0000000E "Label Request Mess ..." Label Resources / 0 0x0000000F "Label Request Mess ..." Available Session Rejected/ 1 0x00000010 "Session Initialization" No Hello Session Rejected/ 1 0x00000011 "Session Initialization" Parameters Advertisement Mode Session Rejected/ 1 0x00000012 "Session Initialization" Parameters Max PDU Length Session Rejected/ 1 0x00000013 "Session Initialization" Parameters Label Range KeepAlive Timer 1 0x00000014 "Events Signaled by ..." Expired Label Request Aborted 0 0x00000015 "Label Abort Request ..." Missing Message 0 0x00000016 "Events Signaled by ..." Parameters
Unsupported Address 0 0x00000017 "FEC Procedures" Family "Address Message Proc ..." Session Rejected/ 1 0x00000018 "Session Initialization" Bad KeepAlive Time Internal Error 1 0x00000019 "Events Signaled by ..." RFC3031] as follows: "The Implicit NULL label is a label with special semantics which an LSR can bind to an address prefix. If LSR Ru, by consulting its ILM (Incoming Label Map) sees that labeled packet P must be forwarded next to Rd, but that Rd has distributed a binding of Implicit NULL to the corresponding address prefix, then instead of replacing the value of the label on top of the label stack, Ru pops the label stack, and then forwards the resulting packet to Rd." The implicit NULL label is represented in LDP as a Generic Label TLV with a Label field value of 3, as defined in [RFC3032].
- Message Types 0x0000 - 0x3DFF. Message types in this range are part of the LDP base protocol. Following the policies outlined in [IANA], Message types in this range are allocated through an IETF Consensus action. - Message Types 0x3E00 - 0x3EFF. Message types in this range are reserved for Vendor-Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-Private Messages"). IANA management of this range of the Message Type Name Space is unnecessary. - Message Types 0x3F00 - 0x3FFF. Message types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the Message Type Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below). IANA], TLV types in this range are allocated through an IETF Consensus action. - TLV Types 0x3E00 - 0x3EFF. TLV types in this range are reserved for Vendor-Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-Private TLVs"). IANA management of this range of the TLV Type Name Space is unnecessary. - TLV Types 0x3F00 - 0x3FFF. TLV types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the TLV Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below).
Following the policies outlined in [IANA], FEC types in the range 0 - 127 are allocated through an IETF Consensus action, types in the range 128 - 191 are allocated as First Come First Served, and types in the range 192 - 255 are reserved for Private Use. IANA], Status Codes in the range 0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as First Come First Served, and codes in the range 0x3F000000 - 0x3FFFFFFF are reserved for Private Use. IANA], Experiment IDs in the range 0x00000000 - 0xefffffff are allocated as First Come First Served and Experiment IDs in the range 0xf0000000 - 0xffffffff are reserved for Private Use.
LSRs directly connected at the link level exchange Basic Hello messages over the link. The threat of spoofed Basic Hellos can be reduced by: o Accepting Basic Hellos only on interfaces to which LSRs that can be trusted are directly connected. o Ignoring Basic Hellos not addressed to the All Routers on this Subnet multicast group. LSRs not directly connected at the link level may use Extended Hello messages to indicate willingness to establish an LDP session. An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting only those originating at sources permitted by an access list. 2. Session communication carried by TCP LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages. [RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application. It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed. To our knowledge, no such TCP option has been defined and deployed. However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward.
labels in the clear. Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label. To avoid label spoofing attacks, it is necessary to ensure that labeled data packets are labeled by trusted LSRs and that the labels placed on the packets are properly learned by the labeling LSRs.
o An LSR SHOULD avoid promiscuous TCP listens for LDP session establishment. It SHOULD use only listens that are specific to discovered peers. This enables it to drop attack packets early in their processing since they are less likely to match existing or in-progress connections. o The use of the MD5 option helps somewhat since it prevents a SYN from being accepted unless the MD5 segment checksum is valid. However, the receiver must compute the checksum before it can decide to discard an otherwise acceptable SYN segment. o The use of access list mechanisms applied at the boundary of the MPLS cloud in a manner similar to that suggested above for Extended Hellos can protect the interior against attacks originating from outside the cloud. Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation. - LDP support for CoS (Class of Service) is not specified in this version. CoS support may be addressed in a future version. - LDP support for multicast is not specified in this version. Multicast support may be addressed in a future version. - LDP support for multipath label switching is not specified in this version. Multipath support may be addressed in a future version. - LDP support for signaling the maximum transmission unit is not specified in this version. It is discussed in the experimental document [LDP-MTU]. - The current specification does not address basic peer discovery on Non-Broadcast Multi-Access (NBMA) media. The solution available in the current specification is to use extended peer
discovery in such setups. The issue of defining a mechanism semantically similar to Basic Discovery (1 hop limit, bind the hello adjacency to an interface) that uses preconfigured neighbor addresses is left for further study. - The current specification does not support shutting down an adjacency. The motivation for doing it and the mechanisms for achieving it are left for further study. - The current specification does not include a method for securing Hello messages, to detect spoofing of Hellos. The scenarios where this is necessary, as well as the mechanism for achieving it are left for future study. - The current specification does not have the ability to detect a stateless fast control plane restart. The method for achieving this, possibly through an "incarnation/instance" number carried in the Hello message, is left for future study. - The current specification does not support an "end of LIB" message, analogous to BGP's "end of RIB" message that an LDP LSR (operating in DU mode) would use following session establishment. The discussion on the need for such a mechanism and its implementation is left for future study. - The current specification does not deal with situations where different LSRs advertise the same address. Such situations typically occur as the result of configuration errors, and the goal in this case is to provide the LSRs advertising the same address with enough information to enable operators to take corrective action. The specification of this mechanism is left for a separate document. RFC 3036 1. Removed the Host Address FEC and references to it, since it is not used by any implementation. 2. Split the reference list into normative and informative references 3. Removed "MPLS using ATM VP Switching" from the list of normative references, and references to it. 4. Removed reference to RFC 1700 and replaced it with a link to http://www.iana.org/assignments/address-family-numbers.
5. Removed reference to RFC 1771 and replaced it with a reference to RFC 4271. 6. Clarified the use of the F-bit. 7. Added option to allow split horizon when doing Ordered Control. 8. Clarified the processing of messages with the U-bit set during the session initialization procedures 9. Clarified the processing of the E-bit during session initialization procedures. 10. Added text explaining that the Shutdown message in the state transition diagram is implemented as a notification message with a Status TLV indicating a fatal error. 11. Added case for TLV length too short in the specification for handling malformed TLVs. 12. Explained the security threat posed by hello spoofing. 13. Added reference to 4271 and 4278 and text for standards maturity variance with regards to the MD5 option. 14. Added text from 3031 explaining the handling of implicit NULL label. 15. Included the encoding of DLCIs to remove normative reference to 3034. 16. Moved references to 3031, 3032, and 3034 to informative. 17. In the section describing handling of unknown TLV, removed reference to inexistent section (errata in original document). 18. Added text clarifying how to achieve interoperability when sending vendor-private TLVs and messages. 19. In the "receive label request" procedures, if a loop is detected, changed the procedure to send a notification before aborting the rest of the processing. 20. In "receive label release" procedures, clarified the behavior for merge-capable LSRs.
21. In "receive label release" procedures, clarified the behavior for receipt of an unknown FEC. 22. In note 4 of "Detect Change in FEC Next Hop", modified the text to reference the correct set of conditions for sending a label request procedure (typo in the original document). 23. In the procedures for "LSR decides to no longer label switch a FEC", clarified the fact that the label must not be reused until a label release is received. 24. In the routine "Prepare_Label_Mapping_Attributes", added a note regarding the treatment of unknown TLVs according to their U and F-bits. 25. In the Address message processing procedures, clarified the behavior for the case where an LSR receives re-advertisement of an address previously advertised it, or withdrawal of an address from an LSR that has not previously advertised that address. 26. In the routine "Receive Label Mapping", clarified the meaning of PrevAdvLabel when no label advertisement message has been sent previously. 27. In the "Receive Label Mapping" procedures, if a loop is detected, modified the procedure to send a notification before aborting the rest of the processing. 28. In the "Receive Label Mapping" procedures, corrected step LMp.10 to handle label mapping messages for additional (non- merged) LSPs for the FEC. 29. In the "Receive Label Mapping" procedures, clarified behavior when receiving a duplicate label for the same FEC. 30. In the routine "Receive Label Abort Request", clarified the behavior for non-merging LSRs. 31. Added the following items to the section discussing areas for future study: o extensions for communicating the maximum transmission unit o basic peer discovery on NBMA media o option of shutting down an adjacency o mechanisms for securing Hello messages o detection of a stateless fast control plane restart o support of "end of LIB" message
o mechanisms for dealing with the case where different LSRs advertise the same address RFC 3036 in January 2001. It was produced by the MPLS Working Group of the IETF and was jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette, and Bob Thomas. The ideas and text in RFC 3036 were collected from a number of sources. We would like to thank Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, and Arun Viswanathan for their input for RFC 3036. The editors would like to thank Eric Gray, David Black, and Sam Hartman for their input to and review of the current document. In addition, the editors would like to thank the members of the MPLS Working Group for their ideas and the support they have given to this document, and in particular, to Eric Rosen, Luca Martini, Markus Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001. [CRLDP] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [LDP-MTU] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, January 2005. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.