draft-ietf-idr-next-hop-capability-00.txt   draft-ietf-idr-next-hop-capability-01.txt 
Network Working Group B. Decraene Network Working Group B. Decraene
Internet-Draft Orange Internet-Draft Orange
Updates: 6790 (if approved) K. Kompella Updates: 6790 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Juniper Networks, Inc.
Expires: December 18, 2017 W. Henderickx Expires: December 31, 2017 W. Henderickx
Nokia Nokia
June 16, 2017 June 29, 2017
BGP Next-Hop dependant capabilities BGP Next-Hop dependent capabilities
draft-ietf-idr-next-hop-capability-00 draft-ietf-idr-next-hop-capability-01
Abstract Abstract
RFC 5492 defines capabilities advertisement for the BGP peer. In RFC 5492 advertises the capabilities of the BGP peer. When the BGP
addition, it is useful to be able to advertise BGP Next-Hop dependant peer is not the same as the BGP Next-Hop, it is useful to also be
capabilities, in particular for forwarding plane features. RFC 5492 able to advertise the capability of the BGP Next-Hop, in particular
is not applicable because the BGP peer may be different from the BGP to advertise forwarding plane features. This document defines a
Next-Hop, in particular when BGP Route Reflection is used. This mechanism to advertise such BGP Next Hop dependent Capabilities.
document defines a mechanism to advertise such BGP Next Hop dependant
Capabilities.
This document defines a new BGP non-transitive attribute to carry This document defines a new BGP non-transitive attribute to carry
Next-Hop Capabilities. This attribute is deleted or possibly Next-Hop Capabilities. This attribute is guaranteed to be deleted or
modified when the BGP Next Hop is changed. updated when the BGP Next Hop is changed, in order to reflect the
capabilities of the new BGP Next-Hop.
This document also defines a Next-Hop capability to advertise the This document also defines a Next-Hop capability to advertise the
ability to handle the MPLS Entropy Label defined in RFC 6790. It ability to process the MPLS Entropy Label as an egress LSR for all
updates RFC 6790 with regard to this BGP signaling. NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard
to this BGP signaling.
Requirements Language Requirements Language
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2017. This Internet-Draft will expire on December 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BGP Next-Hop dependant Capabilities Attribute . . . . . . . . 3 2. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3
2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4 2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4
2.3. Capability Code Operation . . . . . . . . . . . . . . . . 5 2.3. Interpreting received Capability . . . . . . . . . . . . 5
2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5 2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5
3. Entropy Label Next-Hop dependant Capability . . . . . . . . . 6 2.5. Network operation considerations . . . . . . . . . . . . 6
3. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6
3.1. Entropy Label Next-Hop Capability error handling . . . . 7 3.1. Entropy Label Next-Hop Capability error handling . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7
4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 7 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[RFC5492] defines capabilities advertisement for the BGP peer. In [RFC5492] advertises the capabilities of the BGP peer. When the BGP
addition, it is useful to be able to advertise BGP Next-Hop dependant peer is not the same as the BGP Next-Hop, it is useful to also be
capabilities, in particular for forwarding plane features. RFC 5492 able to advertise the capability of the BGP Next-Hop, in particular
is not applicable because the BGP peer may be different from the BGP to advertise forwarding plane features. This document defines a
Next-Hop, in particular when BGP Route Reflection is used. This mechanism to advertise such BGP Next Hop Capabilities.
document defines a mechanism to advertise such BGP Next Hop
Capabilities.
This document defines a new BGP non-transitive attribute to carry This document defines a new BGP non-transitive attribute to carry
Next-Hop Capabilities. When the BGP Next Hop is changed, this Next-Hop Capabilities. This attribute is guaranteed to be deleted or
attribute is deleted or possibly modified to take into account the updated when the BGP Next Hop is changed, in order to reflect the
capabilities of the new BGP Next-Hop. Hence it allows advertising capabilities of the new BGP Next-Hop. Hence it allows advertising
capabilities which are dependent of the BGP Next-Hop. capabilities which are dependent of the BGP Next-Hop.
This attribute advertises the capabilities of the BGP Next-Hop for This attribute advertises the capabilities of the BGP Next-Hop for
the NLRI advertised in the same BGP update. A BGP Next-Hop may the NLRI advertised in the same BGP update. A BGP Next-Hop may
advertise different capabilities for different set of NLRI. advertise different capabilities for different set of NLRI.
This document also defines a first application to advertise the This document also defines a first application to advertise the
capability to handle the MPLS Entropy Label defined in [RFC6790]. capability to handle the MPLS Entropy Label defined in [RFC6790].
Note that RFC 6790 had originally defined a BGP attribute for this Note that RFC 6790 had originally defined a BGP attribute for this
but it has been latter deprecated in [RFC7447]. but it has been latter deprecated in [RFC7447].
2. BGP Next-Hop dependant Capabilities Attribute 2. BGP Next-Hop dependent Capabilities Attribute
2.1. Encoding 2.1. Encoding
The BGP Next-Hop dependant Capabilities Attribute is an optional, The BGP Next-Hop dependent Capabilities Attribute is an optional,
non-transitive BGP Attribute, of value TBD1. The attribute consists non-transitive BGP Attribute, of value TBD1. The attribute consists
of a set of Next-Hop Capabilities. of a set of Next-Hop Capabilities.
The inclusion of a Next-Hop Capability "X" in a BGP UPDATE message, The inclusion of a Next-Hop Capability "X" in a BGP UPDATE message,
indicates that the BGP Next-Hop, encoded in either the NEXT_HOP indicates that the BGP Next-Hop, encoded in either the NEXT_HOP
attribute defined in [RFC4271] or the Network Address of Next Hop attribute defined in [RFC4271] or the Network Address of Next Hop
field of the MP_REACH_NLRI attribute defined in [RFC4760], supports field of the MP_REACH_NLRI attribute defined in [RFC4760], supports
the capability "X" for the NLRI advertised in this BGP UPDATE. the capability "X" for the NLRI advertised in this BGP UPDATE.
This document does not make a distinction between these two Next-Hop This document does not make a distinction between these two Next-Hop
fields and uses the term 'BGP Next-Hop' to refer to whichever one is fields and uses the term 'BGP Next-Hop' to refer to whichever one is
used in a given BGP UPDATE message. used in a given BGP UPDATE message.
A Next-Hop Capability is a triple (Capability Code, Capability A Next-Hop Capability is a triple (Capability Code, Capability
Length, Capability Value) aka a TLV: Length, Capability Value) aka a TLV:
+------------------------------+ +------------------------------+
| Capability Code (1 octet) | | Capability Code (2 octets) |
+------------------------------+ +------------------------------+
| Capability Length (1 octet) | | Capability Length (2 octets) |
+------------------------------+ +------------------------------+
| Capability Value (variable) | | Capability Value (variable) |
~ ~ ~ ~
+------------------------------+ +------------------------------+
Figure 1: BGP Next-Hop Capability Figure 1: BGP Next-Hop Capability
Capability Code: a one-octet unsigned binary integer which indicates Capability Code: a two-octets unsigned binary integer which indicates
the type of "Next-Hop Capability" advertised and unambiguously the type of "Next-Hop Capability" advertised and unambiguously
identifies an individual capability. identifies an individual capability.
Capability Length: a one-octet unsigned binary integer which Capability Length: a two-octets unsigned binary integer which
indicates the length, in octets, of the Capability Value field. A indicates the length, in octets, of the Capability Value field. A
length of 0 indicates that no Capability Value Field is present. length of 0 indicates that no Capability Value field is present.
Capability Value: a variable-length field from 0 to 255 octets. It Capability Value: a variable-length field. It is interpreted
is interpreted according to the value of the Capability Code. according to the value of the Capability Code.
BGP speakers SHOULD NOT include more than one instance of a Next-Hop BGP speakers SHOULD NOT include more than one instance of a Next-Hop
capability with the same Capability Code, Capability Length, and capability with the same Capability Code, Capability Length, and
Capability Value. Note, however, that processing of multiple Capability Value. Note, however, that processing of multiple
instances of such capability does not require special handling, as instances of such capability does not require special handling, as
additional instances do not change the meaning of the announced additional instances do not change the meaning of the announced
capability; thus, a BGP speaker MUST be prepared to accept such capability; thus, a BGP speaker MUST be prepared to accept such
multiple instances. multiple instances.
BGP speakers MAY include more than one instance of a capability (as BGP speakers MAY include more than one instance of a capability (as
identified by the Capability Code) with non-zero Capability Length identified by the Capability Code) with non-zero Capability Length
field, but with different Capability Value and either the same or field, but with different Capability Value and either the same or
different Capability Length. Processing of these capability different Capability Length. Processing of these capability
instances is specific to the Capability Code and MUST be described in instances is specific to the Capability Code and MUST be described in
the document introducing the new capability. the document introducing the new capability.
2.2. Attribute Operation 2.2. Attribute Operation
The BGP Next-Hop dependant Capabilities attribute being non- The BGP Next-Hop dependent Capabilities attribute being non-
transitive, as per [RFC4271], a BGP speaker which does not understand transitive, as per [RFC4271], a BGP speaker which does not understand
it will quietly ignore it and not pass it along to other BGP peers. it will quietly ignore it and not pass it along to other BGP peers.
A BGP speaker that understands the BGP Next-Hop dependant A BGP speaker that understands the BGP Next-Hop dependent
Capabilities Attribute and does not change the BGP Next-Hop, SHOULD Capabilities Attribute and does not change the BGP Next-Hop, SHOULD
NOT change the BGP Next-Hop dependant Capabilities Attribute and NOT change the BGP Next-Hop dependent Capabilities Attribute and
SHOULD pass the attribute unchanged along to other BGP peers. SHOULD pass the attribute unchanged along to other BGP peers.
A BGP speaker that understands the BGP Next-Hop dependant A BGP speaker that understands the BGP Next-Hop dependent
Capabilities Attribute and changes the BGP Next-Hop, MUST remove the Capabilities Attribute and changes the BGP Next-Hop, MUST remove or
received BGP Next-Hop dependant Capabilities Attribute before update the received BGP Next-Hop dependent Capabilities Attribute
propagating the BGP UPDATE to other BGP peers. It MAY attach a new before propagating the BGP UPDATE to other BGP peers. If the
BGP Next-Hop dependant Capabilities attribute describing the capability is not removed, it MUST be updated to only advertise the
capabilities of the new BGP Next-Hop for these NLRIs. capabilities of the new BGP Next-Hop for these NLRIs. An
implementation MAY allow, by configuration, to not advertise some of
the capabilities of a BGP Next-Hop. If a received capability is
unknown, it can't be updated hence unknown capabilities MUST be
removed when the BGP Next-Hop is changed.
2.3. Capability Code Operation The BGP Next-Hop Capability Code MUST reflect the capability of the
router indicated in the BGP Next-Hop, for the NLRI advertised in the
BGP UPDATE. If a BGP speaker sets the BGP Next-Hop to an address of
a different router, it MUST NOT advertise a BGP Next-Hop Capability
not supported by this router for these NLRI.
2.3. Interpreting received Capability
A BGP speaker receiving a BGP Next-Hop Capability Code that it A BGP speaker receiving a BGP Next-Hop Capability Code that it
supports behave as defined in the document defining this Capability supports behave as defined in the document defining this Capability
Code. A BGP speaker receiving a BGP Next-Hop Capability Code that it Code. A BGP speaker receiving a BGP Next-Hop Capability Code that it
does not support MUST ignore this BGP Next-Hop Capability Code. In does not support MUST ignore this BGP Next-Hop Capability Code. In
particular, this MUST NOT be handled as an error. In both cases, the particular, this MUST NOT be handled as an error. In both cases, the
BGP speaker MUST examine the remaining BGP Next-Hop Capability BGP speaker MUST examine the remaining BGP Next-Hop Capability
Code(s) that may be present in the BGP Next-Hop Capabilities Code(s) that may be present in the BGP Next-Hop Capabilities
Attribute. Attribute.
The BGP Next-Hop Capability Code MUST reflect the capability of the
router indicated in the BGP Next-Hop, for the NLRI advertised in the
BGP UPDATE. If a BGP speaker sets the BGP Next-Hop to an address of
a different router (e.g. R), it MUST NOT advertise BGP Next-Hop
Capabilities not supported by this router R for these NLRI.
The presence of a Next-Hop Capability SHOULD NOT influence route The presence of a Next-Hop Capability SHOULD NOT influence route
selection or route preference of a route, unless tunneling is used to selection or route preference, unless tunneling is used to reach the
reach the BGP Next-Hop or the selected route has been learnt from BGP Next-Hop or the selected route has been learnt from EBGP (i.e.
EBGP (i.e. the Next-Hop is in a different AS). Indeed, it is in the Next-Hop is in a different AS). Indeed, it is in general
general impossible for a node to know that all BGP routers of the impossible for a node to know that all BGP routers of the Autonomous
Autonomous System (AS) will understand a given Next-Hop Capability; System (AS) will understand a given Next-Hop Capability; and having
and having different routers, within an AS, use a different different routers, within an AS, use a different preference for a
preference for a route, may result in forwarding loops if tunnelling route, may result in forwarding loops if tunnelling is not used to
is not used to reach the BGP Next-Hop. reach the BGP Next-Hop.
An implementations MAY allow, by configuration, removing this
attribute or specific Next-Hop capabilities when advertising the
routes over EBGP.
2.4. Attribute Error Handling 2.4. Attribute Error Handling
A BGP Next-Hop dependant Capabilities Attribute is considered A BGP Next-Hop dependent Capabilities Attribute is considered
malformed if the length of the Attribute is not equal to the sum of malformed if the length of the Attribute is not equal to the sum of
all (BGP Next-Hop dependant Capability Length +2) of the capabilities all (BGP Next-Hop dependent Capability Length +4) of the capabilities
carried in this attribute. Note that "2" is the length of the fields carried in this attribute. Note that "4" is the length of the fields
"Type" and "Length" of each BGP Next Hop dependant Capability, as the "Type" and "Length" of each BGP Next Hop dependent Capability, as the
capability length only account for the length of the Value field. capability length only account for the length of the Value field.
A BGP UPDATE message with a malformed BGP Next-Hop dependent
Capabilities Attribute SHALL be handled using the approach of
"attribute discard" defined in [RFC7606].
Unknown Next-Hop Capabilities Codes MUST NOT be considered as an
error.
A document that specifies a new Next-Hop Capability SHOULD provide A document that specifies a new Next-Hop Capability SHOULD provide
specifics regarding what constitutes an error for that Next-Hop specifics regarding what constitutes an error for that Next-Hop
Capability. Capability.
A BGP UPDATE message with a malformed BGP Next-Hop dependant If a Next-Hop dependent Capability is malformed, this Capability MUST
Capabilities Attribute SHALL be handled using the approach of be ignored and removed. Others Next-Hop Capabilities MUST be
"attribute discard" defined in [RFC7606]. processed as usual.
Unknown Next-Hop Capabilities Codes MUST NOT be considered as an 2.5. Network operation considerations
error. They MUST be silently ignored.
If a Next-Hop dependant Capability is malformed, this Next-Hop In the corner case where multiple nodes use the same IP address as
Capability Type MUST be ignored. Others Next-Hop Capabilities MUST their BGP Next-Hop, aka anycast nodes as described in [RFC4786], a
be processed as usual. BGP speaker MUST NOT advertise a given Next-Hop Capability unless all
nodes sharing this same IP address support this Next-Hop Capability.
The network operator operating those anycast nodes is responsible for
enforcing that an anycast node does not advertise a BGP Next-Hop
capability not supported by all nodes advertising this anycast
address. This can be performed by using anycast nodes sharing the
same capabilities or by filtering the BGP Next-Hop Capabilities which
are not shared by all anycast nodes.
3. Entropy Label Next-Hop dependant Capability For security considerations, a network operator may want to filter
the BGP Next-Hop capabilities advertised to external Autonomous
Systems.
3. Entropy Label Next-Hop dependent Capability
The Entropy Label Next-Hop Capability has type code 1 and a length of The Entropy Label Next-Hop Capability has type code 1 and a length of
0 or 1 octet. 0 octet.
The inclusion of the "Entropy Label" Next-Hop Capability indicates The inclusion of the "Entropy Label" Next-Hop Capability indicates
that the BGP Next-Hop can be sent packets, for all routes indicated that the BGP Next-Hop can be sent packets, for all routes indicated
in the NRLI, with a MPLS entropy label (ELI, EL) added immediately in the NRLI, with a MPLS entropy label (ELI, EL) added immediately
after the label stack advertised with the NLRI. after the label stack advertised with the NLRI.
On the receiving side, suppose BGP speaker S has determined that On the receiving side, suppose BGP speaker S has determined that
packet P is to be forwarded according to BGP route R, where R is a packet P is to be forwarded according to BGP route R, where R is a
route of one of the labeled address families. And suppose that L is route of one of the labeled address families. And suppose that L is
the label stack embedded in the NLRI of route R. Then to forward the label stack embedded in the NLRI of route R. Then to forward
skipping to change at page 7, line 5 skipping to change at page 7, line 22
o Egress case: NH is the egress of the LSP advertised with the NLRI o Egress case: NH is the egress of the LSP advertised with the NLRI
and its capable of handling the ELI during the lookup of the MPLS and its capable of handling the ELI during the lookup of the MPLS
top label. top label.
o Transit LSR case: NH is a transit LSR for the LSP advertised with o Transit LSR case: NH is a transit LSR for the LSP advertised with
the NLRI (i.e. NH swaps one of the label advertised in the NLRI) the NLRI (i.e. NH swaps one of the label advertised in the NLRI)
and next downstream BGP Next-Hop(s) has(have) advertised the and next downstream BGP Next-Hop(s) has(have) advertised the
Entropy Label Next-Hop Capability (or a similar capability Entropy Label Next-Hop Capability (or a similar capability
signalled by protocol P if the route is redistributed, by NH, from signalled by protocol P if the route is redistributed, by NH, from
protocol P to BGP). protocol P into BGP).
3.1. Entropy Label Next-Hop Capability error handling 3.1. Entropy Label Next-Hop Capability error handling
If the Entropy Label Next-Hop Capability is present more than once, If the Entropy Label Next-Hop Capability is present more than once,
it MUST be considered as received once with a length of 0. it MUST be considered as received once with a length of 0.
If the Entropy Label Next-Hop Capability is received with a length If the Entropy Label Next-Hop Capability is received with a length
other than 0 or 1, it is not considered malformed, but its semantics other than 0, it is not considered malformed, but its semantics are
are exactly the same as if it had a length of 1. In other words, exactly the same as if it had a length of 0. In other words,
additional octets MUST be ignored. This is to allow for graceful additional octets MUST be ignored. This is to allow for graceful
future extension. future extension.
4. IANA Considerations 4. IANA Considerations
4.1. Next-Hop Capabilities Attribute 4.1. Next-Hop Capabilities Attribute
IANA is requested to allocate a new Path Attribute, called "Next-Hop IANA is requested to allocate a new Path Attribute, called "Next-Hop
Capabilities", type Code TBD1, from the "BGP Path Attributes" Capabilities", type Code TBD1, from the "BGP Path Attributes"
registry. registry.
4.2. Next-Hop Capability registry 4.2. Next-Hop Capability registry
The IANA is requested to create and maintain a registry entitled The IANA is requested to create and maintain a registry entitled "BGP
"Next-Hop Capabilities". Next-Hop Capabilities".
The registration policies [RFC5226] for this registry are: The registration policies [RFC8126] for this registry are:
1-63 IETF Review 1-63 IETF Review
64-127 First Come First Served 64-65534 First Come First Served
128-250 Standards Action 65535 Reserved
251-254 Experimental Use
255 Reserved
IANA is requested to make the following initial assignments: IANA is requested to make the following initial assignments:
Registry Name: Next-Hop Capability. Registry Name: Next-Hop Capability.
Value Meaning Reference Value Meaning Reference
---------- ---------------------------------------- --------- ---------- ---------------------------------------- ---------
0 Reserved (not to be allocated) This document 0 Reserved (not to be allocated) This document
1 Entropy Label This document 1 Entropy Label This document
2-250 Unassigned 2-65534 Unassigned
251-254 Experimental This document 65535 Reserved for future registry extension This document
255 Reserved (for futur registry extension) This document
5. Security Considerations 5. Security Considerations
This document does not introduce new security vulnerabilities in BGP. This document does not introduce new security vulnerabilities in BGP.
Specifically, an operator who is relying on the information carried Specifically, an operator who is relying on the information carried
in BGP must have a transitive trust relationship back to the source in BGP must have a transitive trust relationship back to the source
of the information. Specifying the mechanism(s) to provide such a of the information. Specifying the mechanism(s) to provide such a
relationship is beyond the scope of this document. Please refer to relationship is beyond the scope of this document. Please refer to
the Security Considerations section of [RFC4271] for security the Security Considerations section of [RFC4271] for security
mechanisms applicable to BGP. mechanisms applicable to BGP.
The advertisement of BGP Next-Hop capabilities to EBGP peers may
disclose, to the peer AS, some capabilities of the BGP node and may
help fingerprinting its hardware model and software version. This
may be mitigated by filtering the capability advertised to EBGP
peers.
Security of the Entropy Label capability advertisement is unchanged
compared to [RFC6790] which first defined this signaling.
6. Acknowledgement 6. Acknowledgement
The Entropy Label Next-Hop Capability defined in this document is The Entropy Label Next-Hop Capability defined in this document is
based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. based on the ELC BGP attribute defined in section 5.2 of [RFC6790].
The authors wish to thank John Scudder for the discussions on this The authors wish to thank John Scudder for the discussions on this
topic and Eric Rosen for his in-depth review of this document. topic and Eric Rosen for his in-depth review of this document.
The authors wish to thank Jie Dong for his review and comments. The authors wish to thank Jie Dong and Robert Raszuk for their review
and comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>. <http://www.rfc-editor.org/info/rfc4760>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>. <http://www.rfc-editor.org/info/rfc6790>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References 7.2. Informative References
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>. 2009, <http://www.rfc-editor.org/info/rfc5492>.
[RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy
Label Capability Attribute", RFC 7447, Label Capability Attribute", RFC 7447,
DOI 10.17487/RFC7447, February 2015, DOI 10.17487/RFC7447, February 2015,
<http://www.rfc-editor.org/info/rfc7447>. <http://www.rfc-editor.org/info/rfc7447>.
Appendix A. Changes / Author Notes
[RFC Editor: Please remove this section before publication]
Changes -01:
o Capability code and length encoded over 2 octets (from one). IANA
registry is now mainly FCFS.
o Addition of section "Network operation considerations", in
particular to discuss anycast nodes.
o Enhanced Security consideration (capability advertised to external
ASes).
o Editorial changes and typo corrections.
Authors' Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
 End of changes. 49 change blocks. 
101 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/