One document matched: draft-vandevelde-idr-remote-next-hop-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-vandevelde-idr-remote-next-hop-00"
ipr="trust200902" updates="792, 4443">
<front>
<title abbrev="">BGP Remote-Next-Hop</title>
<author fullname="Gunter Van de Velde" initials="G."
surname="Van de Velde">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</postal>
<phone>+32 2704 5473</phone>
<email>gvandeve@cisco.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K."
surname="Patel">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<city>San Jose, CA 95124</city>
<country>USA</country>
<code>95134</code>
</postal>
<phone>+32 2704 5473</phone>
<email>keyupate@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Operations and Management</area>
<workgroup>Operational Security</workgroup>
<abstract>
<t>The BGP Remote-Next-Hop optional transitive attribute, provides an additional level of
recursive route-lookup. The BGP Remote-Next-Hop attribute can be used, both on the
public Internet infrastructure and within public or private Autonomous Systems (AS).
The usage of BGP Remote-Next-Hop operates as ships-in-the-night and does not require
any capability exchange for any BGP Session. BGP Remote-Next-Hop is providing the
distribution of one or more Location Identifiers assigned to a particular BGP
prefix or an NLRI. To secure the BGP prefix or NLRI entry BGP security
mechanisms, either RPKI or other BGP mechanisms can be utilized.
</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>Each IP address (v4 or v6) represents a location and an identity. This is captured and
developed by Locator Identity Split Protocol (LISP) and additionally documented by rfc6227
(Design Goals for Scalable Internet Routing) to scale the Internet.
</t>
<t>The optional transitive BGP Remote-Next-Hop attribute provides a mapping to complement
and support mapping technologies (i.e. LISP) by using using BGP to distribute either a single or a set of locators
attached to each entry in the BGP table. Based upon this locater information (the BGP
Remote-Next-Hop) an overlay tunnel can be utilized and created. This overlay tunnel could
be any type of IPv4-in-IPv4, IPv6-in-IPv4, IPv4-in-IPv6 or IPv6-in-IPv6,
</t>
<t>If a recipient node has no awareness or does not understand the BGP Remote-Next-Hop attribute
then traditional BGP routing can be used as fallback mechanism. If the recipient node does
understand the BGP Remote-Next-Hop attribute, then an overlay tunnel could be
created i.e a LISP or IPoGRE tunnel.
</t>
<t>In addition, existing BGP security mechanisms can be used to verify the correctness of
the BGP update including the validity of the BGP Remote-Next-Hop attribute.
This will make sure that recipients of the BGP NLRI update which understand BGP Remote-Next-Hop,
are not by accident tunneling to a malicious intermediate hop instead of the rightful BGP end-point.
</t>
<t>This note is defining the attribute for usage on Inter-AS and Intra-AS environments.
</t>
<t>Note that the Address Family (AF) of the NLRI exchanged is intended to be independent
of the Address Family of the BGP Remote-Next-Hop attribute; hence
the BGP Remote-Next-Hop attribute can be used within and between AF environments.
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Option Format: BGP Remote-Next-Hop">
<section title="BGP Option Type">
<t>
Optional Transitive
</t>
</section>
<section title="Option Format">
<figure>
<artwork>
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Remote-Next-Hop Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Bit 0: Set to 1 (Optional Attribute);</t>
<t>Bit 1: Set to 1 (Transitional Attribute);</t>
<t>Bit 2: Partial bit of the attribute; </t>
<t>Depending on the size and entries within the BGP Remote-Next-Hop the attribute may be complete (set to 0) or partial (set to 1);</t>
<t>Bit 3: Extended Length bit; </t>
<t>Set to 0 if non-extended; </t>
<t>Set to 1 if Extended length;</t>
<t>Bit 4 to 7 Set to 0;</t>
<t>Bit 8 to 15: Set to BGP Remote-Next-Hop attribute. Value to be defined by IANA;
</t>
</section>
<section title="Remote-Next-Hop Attribute Format">
<t>The general format of this attribute describes the structure of the BGP Remote-Next-Hop attribute. Each
attribute address family MUST be carried in a different Remote-Next-Hop container.
(For example IPv4 and IPv6 will each need their own container)
</t>
<t>Each attribute can cary multiple BGP Remote-Next-Hop addresses.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| BGP Remote-Next-Hop |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The coding mentioned here is Hexadecimals.</t>
<t>If Address Family is set to 0 then it are IPv4 addresses.</t>
<t>If Address Family is set to 1 then it are IPv6 addresses.</t>
<t>Other values are reserved for the future purposes.</t>
<t>The length field is encoded in number of Octets.</t>
<t>BGP Remote-Next-Hop: the BGP Remote-Next-Hop addresses.</t>
</section>
</section>
<section title="Usage Guidelines">
<t>This section provides a short overview of some use-case scenarios
for the BGP Remote-Next-Hop attribute. The usage of the BGP
Remote-Next-Hop attribute is not limited to the examples
discussed in this section.
</t>
<section title="Networks that do NOT support BGP Next-Hop-Attribute">
<t>If a device does not support this attribute, then due to the
Optional Transitive BGP character of this attribute will
result that traditional routing is utilized with all the benefits
and drawbacks.
</t>
</section>
<section title="Multi-homing for IPv6">
<t>When an IPv6 network is multi-homed towards the Internet, then it
may be assigned with more than a single prefix. While the aspiration
for these different assignments is to reduce the size of the Global
Internet Routing table, it also results in well known resiliency issues
discussed in a few IETF Working groups (if attribute idea gets accepted
by WG, references will be added).
</t>
<t>The BGP Remote-Next-Hop attribute is providing a technology to glue
these assigned IPv6 prefixes together and avoid some of the well
known resiliency issues.
</t>
<t>So, how does this concept work?
</t>
<t>Assume you have a Node (=Source-Node) on Network (=Source-Network) and you would
like to send something to your peer (Destination-Node) which is a device in
Network (Destination-Network). With traditional routing a destination lookup
is done, and forwarded each hop between Source-Node and Destination-node.
</t>
<t>What the attribute BGP Remote-Next-Hop provides is that when the Source-Node
sends a packet to the Destination-Node it can be specially handled by the
Source-Network edge-router. This device will look at the destination address of
the packet, and check the BGP Remote-Next-Hop attribute (assuming that the edge-node
supports that idea). That lookup will allow a device understanding the attribute, to select
or create a tunnel towards the destination.
</t>
<t>Using this will result in having organizations built Internet overlays.
</t>
</section>
<section title="Mapping Technology to compliment LISP">
<t>LISP, the Locator ID Split protocol, makes usage of a mapping technology to build
up the tunnels to accommodate LISP. What this BGP Remote-Next-Hop attribute
is providing is that it provides a mechanism to distribute tunnel end-points
using existing BGP infrastructure without the need of anybody requiring to enable
it. As result it will be ship in the night from both BGP as LISP perspective.
</t>
</section>
<section title="Network Overlay Infrastructure">
<t>With the BGP Remote-Next-Hop feature it is possible to build and create an overlay
tunneled network. By using this attribute, it is possible to have individual (Internet)
Networks create sessions between them and make sure that the Internet and
serviceability elements are kept correctly.
</t>
</section>
<section title="Reduction of the Routing Forwarding Information Base">
<t>Right now there are about 50.000 Autonomous Systems distributed, which is way less as the
useful entries in the existing FIB. The usage of double recursive reduction
has as result that even if the routing table stays equal size, that the
FIB (Traditionally ASIC Based Forwarding Table) when everybody is using this
technology is reduced. ( We would go from 400K entries to 50k entries in the FIB).
</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for a new BGP Attribute assignment.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This technology could be used as technology as man in the middle
attack, however with existing RPKI validation for BGP that risk is reduced.</t>
<t>Additional risks are still to be analysed by the working group and feedbacck received on the draft</t>
<section anchor="Privacy" title="Privacy Considerations">
<t>This proposal could introduce privacy issues, however with BGP
security mechanisms in place they are removed.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>To be completed </t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">16 May 2012</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0792" ?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6227" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:39 |