draft-ietf-idr-next-hop-capability-03.txt   draft-ietf-idr-next-hop-capability-04.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 28, 2018 W. Henderickx Expires: June 20, 2019 W. Henderickx
Nokia Nokia
June 26, 2018 December 17, 2018
BGP Next-Hop dependent capabilities BGP Next-Hop dependent capabilities
draft-ietf-idr-next-hop-capability-03 draft-ietf-idr-next-hop-capability-04
Abstract Abstract
RFC 5492 advertises the capabilities of the BGP peer. When the BGP RFC 5492 advertises the capabilities of the BGP peer. When the BGP
peer is not the same as the BGP Next-Hop, it is useful to also be peer is not the same as the BGP Next-Hop, it is useful to also be
able to advertise the capability of the BGP Next-Hop, in particular able to advertise the capability of the BGP Next-Hop, in particular
to advertise forwarding plane features. This document defines a to advertise forwarding plane features. This document defines a
mechanism to advertise such BGP Next Hop dependent Capabilities. mechanism to advertise such BGP Next Hop dependent Capabilities.
This document defines a new BGP non-transitive attribute to carry This document defines a new BGP non-transitive attribute to carry
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 28, 2018. This Internet-Draft will expire on June 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
3.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 7 3.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 7
3.2. Entropy Label Next-Hop Capability error handling . . . . 9 3.2. Entropy Label Next-Hop Capability error handling . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9
4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 11 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC5492] advertises the capabilities of the BGP peer. When the BGP [RFC5492] advertises the capabilities of the BGP peer. When the BGP
peer is not the same as the BGP Next-Hop, it is useful to also be peer is not the same as the BGP Next-Hop, it is useful to also be
able to advertise the capability of the BGP Next-Hop, in particular able to advertise the capability of the BGP Next-Hop, in particular
to advertise forwarding plane features. This document defines a to advertise forwarding plane features. This document defines a
mechanism to advertise such BGP Next Hop Capabilities. mechanism to advertise such BGP Next Hop Capabilities.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
BGP speaker MUST NOT advertise a given Next-Hop Capability unless all BGP speaker MUST NOT advertise a given Next-Hop Capability unless all
nodes sharing this same IP address support this Next-Hop Capability. nodes sharing this same IP address support this Next-Hop Capability.
The network operator operating those anycast nodes is responsible for The network operator operating those anycast nodes is responsible for
enforcing that an anycast node does not advertise a BGP Next-Hop enforcing that an anycast node does not advertise a BGP Next-Hop
capability not supported by all nodes advertising this anycast capability not supported by all nodes advertising this anycast
address. This can be performed by using anycast nodes sharing the address. This can be performed by using anycast nodes sharing the
same capabilities or by filtering the BGP Next-Hop Capabilities which same capabilities or by filtering the BGP Next-Hop Capabilities which
are not shared by all anycast nodes. are not shared by all anycast nodes.
For security considerations, a network operator may want to filter For security considerations, a network operator may want to filter
the BGP Next-Hop capabilities advertised to external Autonomous the BGP Next-Hop capabilities advertised from or to external
Systems. Autonomous Systems on a per capability, capability type or attribute
basis.
3. Entropy Label Next-Hop dependent Capability 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 or 1 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.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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.
As this attribute is removed when the BGP Next-Hop is changed, the
source of the information is the router which IP address is indicated
in the BGP Next-Hop. Such Next-Hop is typically either within the AS
when a BGP Next-Hop Self policy is configured, or in the neighboring
AS with which an interconnection and an EBGP has been established.
If this neighboring AS is not trusted with regards to information
carried in the BGP attribute, or carried in a specific capability,
this attribute or specific capability should be removed when
received. Note that in some cases, this Next-Hop may advertise
information based on information it has received from its own
downstream BGP Next-Hop, hence the transitive trust relationship. If
the underlying transport between both ASes is not trusted, BGP
transport should be protected for integrity and authentification.
The advertisement of BGP Next-Hop capabilities to EBGP peers may The advertisement of BGP Next-Hop capabilities to EBGP peers may
disclose, to the peer AS, some capabilities of the BGP node and may disclose, to the peer AS, some capabilities of the BGP node and may
help fingerprinting its hardware model and software version. This help fingerprinting its hardware model and software version. This
may be mitigated by filtering the capability advertised to EBGP may be mitigated by filtering the capability advertised to EBGP
peers. peers.
Security of the Entropy Label capability advertisement is unchanged Security of the Entropy Label capability advertisement is unchanged
compared to [RFC6790] which originally defined this signaling. compared to [RFC6790] which originally defined this signaling.
6. Acknowledgement 6. Acknowledgement
skipping to change at page 11, line 20 skipping to change at page 11, line 35
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-spring-entropy-label] [I-D.ietf-mpls-spring-entropy-label]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy label for SPRING Shakir, R., and J. Tantsura, "Entropy label for SPRING
tunnels", draft-ietf-mpls-spring-entropy-label-11 (work in tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in
progress), May 2018. progress), July 2018.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://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, <https://www.rfc-editor.org/info/rfc5492>. 2009, <https://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
skipping to change at page 12, line 9 skipping to change at page 12, line 26
o Enhanced Security consideration (capability advertised to external o Enhanced Security consideration (capability advertised to external
ASes). ASes).
o Editorial changes and typo corrections. o Editorial changes and typo corrections.
Changes -02: No change. Refresh only. Changes -02: No change. Refresh only.
Changes -03: Addition of the optional Readable Label Depth. Changes -03: Addition of the optional Readable Label Depth.
Changes -04: No change. Refresh only.
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. 9 change blocks. 
9 lines changed or deleted 26 lines changed or added

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