Internet Engineering Task Force                            P. Christian INTERNET DRAFT                                       Christian Tena LTD                                                          September 2002                              TLV for Proprietary Use                     Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited.         1. Abstract        This document defines a TLV that may be used by any individual,    company or other organisation for vendor specific or experimental    extensions to the IS-IS routing protocol, and defines the format of    the TLV.         2. Conventions used in this document        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 RFC 2119.           Christian Expires March 2003 1 Internet Draft September 2002                        TLV for Proprietary Use   3. Introduction        IS-IS as defined in [1] has always been an extensible routing    protocol.  Extensions to IS-IS are encoded as a TLV.  Critically [1]    has always defined that when an IS-IS router receives an LSP, that it SHALL process the parts of the LSP that it understands, and SHALL flood the entire LSP, including all TLVs whether they are understood or not, on to other routers in the network.        Thus information that is encoded into a TLV and placed in an LSP by    a router will be propagated to every other router in an IS-IS level-    1 area or level-2 subdomain, even by implementations that were never designed with that particular TLV in mind.        The basic function of an IS-IS TLV is identified by the first byte    of the TLV (the code).  Thus there are only 256 possible TLV codes.     Certain TLVs have been defined to include sub-TLVs so that a single    TLV code can be used for multiple functions.        No single authority assigns TLV codes, [3] lists most known TLV    codes at this time.  Also no TLV code was ever defined for private, proprietary or experimental use.        The extensible nature of IS-IS has made the use of TLVs in LSPs for    proprietary purposes so useful that in the absence of a central    authority for assigning TLV type numbers vendors have occasionally    simply chosen a number and hoped for the best.  The risk is that    such a TLV code may then be chosen by another organization at a    later time for a different function, thus creating an    interoperability problem. Also this accelerates the depletion of the    256 possible TLV codes.        This document specifies a TLV that may be used for proprietary, private or experimental purposes, and a mechanism that insures that different implementations using this TLV can exist in the same network without creating interoperability problems.        By using this new TLV, companies, individuals or institutions may    use extensions to IS-IS without fear of interoperability problems    with other organizations in the future, and the available pool of    TLV codes will no longer be diminished by proprietary use.       4. TLV code for proprietary use        The code for this TLV SHALL be 250.        TLVs that use 250 for the code field MUST include a valid IEEE    assigned OUI as the first three bytes of the value of the TLV. The structure of the TLV is should in the diagram below. Christian Expires March 2003 2 Internet Draft September 2002                        TLV for Proprietary Use No. of Octets +---------------------------+ | CODE =250 | 1 +---------------------------+ | LENGTH =n+3 | 1 +---------------------------+ | OUI | 3 +---------------------------+ | DATA | n +---------------------------+ Structure of the Proprietary TLV The three octet OUI plus the data octets together constitute a normal IS-IS variable length value field. The length field MUST be set to the number of octets of data plus three. For more information about OUIs refer to [4].    On receipt of an LSP a router MAY ignore TLVs of type 250 that    include an OUI from a different organization, but MUST flood the LSP    onwards as per [1].           After the first three bytes of the value field of the TLV subsequent    bytes may be used freely for any purpose provided that the resultant    TLV is conformant with [1].        Many organizations will have access to only one or a few OUIs.     Implementers are free to format the value field after their OUI into    sub-TLVs so that the TLV may be used for multiple purposes, and would be well advised to do so. 5. Using proprietary information to modify SPF All routers in an IS-IS routed network need to calculate routes such that they all arrive at the same shortest path for a given destination. If this does not happen then routing loops and blackholes are likely to occur. Therefore a router MUST NOT calculate a route differently due to information that it receives in a proprietary TLV. Shortest paths MUST continue to be calculated as per [1] and [2]. Christian Expires March 2003 3 Internet Draft September 2002                        TLV for Proprietary Use 6. Correct use of Proprietary TLV in LSPs Some implementations recalculate SPF each time that they receive a new LSP. In the least case an implementation needs to decide whether a new LSP is significant or not. If one router constantly transmits LSPs into the network then others may not perform well. Additionally LSPs are flooded to every router in a level-1 area or level-2 subdomain, and are therefore not a particularly efficient way of carrying a piece of information simply from router A to router B. Consequently the proprietary TLV SHOULD NOT be used within LSPs as any kind of general transport mechanism, and the proprietary TLV SHOULD NOT cause frequent transmission of LSPs into the network. In general it would be preferable to transmit information in a proprietary TLV at such time as an LSP would be normally be transmitted anyway, if this is possible. These particular restrictions do not apply to use of the proprietary TLV in Hello and Sequence Number packets.     7. Security Considerations    The contents of IS-IS PDUs are not protected by encryption,    so the contents of TLVs in LSPs are visible throughout the    routing area or domain, while the contents of Hello Packets,    CSNPs, and PSNPs are visible to observers on the link they    are sent to.  The addition of MD5 authentication, as described    in [5] can increase the integrity of TLVs, while encryption could increase their confidentiality.     The general extensibility of the TLV mechanism has always allowed    the addition of new information, and the possibility of conflicting    interpretations of such information by different implementations.     This proposal does not introduce a new quality of information; it    simply allows an increase in the quantity of such additions.  As    such, it represents no new security issues for IS-IS. Christian Expires March 2003 4 Internet Draft September 2002                        TLV for Proprietary Use     8. References        [1] ISO, "Intermediate system to Intermediate system routeing    information exchange protocol for use in conjunction with the    Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992. [2] RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments, R Callon, December 1990        [3] RFC 3359, Reserved TLV Codepoints in ISIS Tony Przygienda, August 2002 [4] IEEE OUI and Company_id Assignments http://standards.ieee.org/regauth/oui/index.shtml [5] draft-ietf-isis-hmac-03.txt, IS-IS Cryptographic Authentication Tony Li, RJ Atkinson, July 2001 9. Acknowledgments        The author takes no credit for this work as the concept was    discussed in the IS-IS Working Group before the author even became    an active participant.  Suggestions for acknowledgement gladly    received.     10. Author's Addresses        Philip Christian    Christian Tena LTD    Hatfield Heath    Essex, CM22 7AH UK        Email: philip.christian@christiantena.co.uk Christian Expires March 2003 5