1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc7447.txt b/doc/rfc/rfc7447.txt
new file mode 100644
index 0000000..2676c6f
--- /dev/null
+++ b/doc/rfc/rfc7447.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Scudder
+Request for Comments: 7447                                   K. Kompella
+Updates: 6790                                           Juniper Networks
+Category: Standards Track                                  February 2015
+ISSN: 2070-1721
+
+
+         Deprecation of BGP Entropy Label Capability Attribute
+
+Abstract
+
+   The BGP Entropy Label Capability attribute is defined in RFC 6790.
+   Regrettably, it has a bug: although RFC 6790 mandates that routers
+   incapable of processing Entropy Labels must remove the attribute,
+   fulfillment of this requirement cannot be guaranteed in practice.
+   This specification deprecates the attribute.  A forthcoming document
+   will propose a replacement.
+
+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/rfc7447.
+
+Copyright Notice
+
+   Copyright (c) 2015 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.
+
+
+
+
+
+Scudder & Kompella           Standards Track                    [Page 1]
+
+RFC 7447                   Deprecation of ELCA             February 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
+   2.  Deprecation of ELCA . . . . . . . . . . . . . . . . . . . . .   2
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   3
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   3
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4
+
+1.  Introduction
+
+   [RFC6790] defines the Entropy Label Capability attribute (ELCA), an
+   optional, transitive BGP path attribute.  For correct operation, an
+   intermediate node modifying the next hop of a route must remove the
+   ELCA unless the node doing so is able to process entropy labels.
+   Sadly, this requirement cannot be fulfilled with the ELCA as
+   specified, because it is an optional, transitive attribute.  By
+   definition, a node that does not support the ELCA will propagate the
+   attribute (this is a general property of optional, transitive
+   attributes; see [RFC4271]).  But such an ELCA-oblivious node is
+   likely to be incapable of processing entropy labels and is exactly
+   the node that we desire to remove the attribute!
+
+   This specification updates RFC 6790 by deprecating the version of
+   ELCA defined in Section 5.2 of that document.  A forthcoming document
+   will propose a replacement.  All other sections of RFC 6790 are
+   unchanged.
+
+1.1.  Requirements Language
+
+   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 [RFC2119].
+
+2.  Deprecation of ELCA
+
+   This document deprecates the ELCA path attribute.  This means that
+   implementations MUST NOT generate the attribute.  If received, the
+   attribute MUST be treated as any other unrecognized optional,
+   transitive attribute as per [RFC4271], until and unless the code
+   point is reused by some new specification.  (To the authors' best
+   knowledge, there are no implementations of ELCA at the time of
+   writing.)
+
+
+
+
+Scudder & Kompella           Standards Track                    [Page 2]
+
+RFC 7447                   Deprecation of ELCA             February 2015
+
+
+3.  IANA Considerations
+
+   For the reasons given in Section 1, IANA has marked attribute 28 "BGP
+   Entropy Label Capability Attribute" in the "BGP Path Attributes"
+   registry as "deprecated" and has added a reference to this RFC.
+
+4.  Security Considerations
+
+   ELCA, as defined in Section 5.2 of [RFC6790], has in common with
+   other optional, transitive path attributes the property that it will
+   be "tunneled" through intervening routers that don't implement the
+   relevant specification.  Unfortunately, as discussed elsewhere in
+   this document, implementations of ELCA that receive such "tunneled"
+   attributes could -- sometimes improperly -- rely on them.  The
+   consequence of doing so could be a black hole in the forwarding path
+   for the affected routes.  Whether or not this is a new security issue
+   is somewhat debatable, since an attacker would have to be part of the
+   control-plane path for the route in question in order for the
+   attacker to exploit the issue.  Under those circumstances, an
+   attacker already has a panoply of mischief-making tools available, as
+   discussed in [RFC4272].
+
+   In any case, this document renders any real or imagined security
+   issues with ELCA moot, by deprecating it.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
+              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
+              RFC 6790, November 2012,
+              <http://www.rfc-editor.org/info/rfc6790>.
+
+5.2.  Informative References
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+              2006, <http://www.rfc-editor.org/info/rfc4271>.
+
+   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
+              4272, January 2006,
+              <http://www.rfc-editor.org/info/rfc4272>.
+
+
+
+
+Scudder & Kompella           Standards Track                    [Page 3]
+
+RFC 7447                   Deprecation of ELCA             February 2015
+
+
+Acknowledgements
+
+   Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, John Drake,
+   Adrian Farrel, Keyur Patel, Ravi Singh, and Kevin Wang for their
+   discussion of this issue.
+
+Authors' Addresses
+
+   John G. Scudder
+   Juniper Networks
+
+   EMail: jgs@juniper.net
+
+
+   Kireeti Kompella
+   Juniper Networks
+
+   EMail: kireeti@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Scudder & Kompella           Standards Track                    [Page 4]
+