idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4443, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC792, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC792, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2012) is 4345 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC6227' is defined on line 306, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security G. Van de Velde 3 Internet-Draft K. Patel 4 Updates: 792, 4443 (if approved) Cisco Systems 5 Intended status: Standards Track May 24, 2012 6 Expires: November 25, 2012 8 BGP Remote-Next-Hop 9 draft-vandevelde-idr-remote-next-hop-00 11 Abstract 13 The BGP Remote-Next-Hop optional transitive attribute, provides an 14 additional level of recursive route-lookup. The BGP Remote-Next-Hop 15 attribute can be used, both on the public Internet infrastructure and 16 within public or private Autonomous Systems (AS). The usage of BGP 17 Remote-Next-Hop operates as ships-in-the-night and does not require 18 any capability exchange for any BGP Session. BGP Remote-Next-Hop is 19 providing the distribution of one or more Location Identifiers 20 assigned to a particular BGP prefix or an NLRI. To secure the BGP 21 prefix or NLRI entry BGP security mechanisms, either RPKI or other 22 BGP mechanisms can be utilized. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 25, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 60 1.2. Option Format: BGP Remote-Next-Hop . . . . . . . . . . . . 3 61 1.2.1. BGP Option Type . . . . . . . . . . . . . . . . . . . . 3 62 1.2.2. Option Format . . . . . . . . . . . . . . . . . . . . . 4 63 1.2.3. Remote-Next-Hop Attribute Format . . . . . . . . . . . 4 64 1.3. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5 65 1.3.1. Networks that do NOT support BGP Next-Hop-Attribute . . 5 66 1.3.2. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . 5 67 1.3.3. Mapping Technology to compliment LISP . . . . . . . . . 6 68 1.3.4. Network Overlay Infrastructure . . . . . . . . . . . . 6 69 1.3.5. Reduction of the Routing Forwarding Information 70 Base . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 74 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 Each IP address (v4 or v6) represents a location and an identity. 84 This is captured and developed by Locator Identity Split Protocol 85 (LISP) and additionally documented by rfc6227 (Design Goals for 86 Scalable Internet Routing) to scale the Internet. 88 The optional transitive BGP Remote-Next-Hop attribute provides a 89 mapping to complement and support mapping technologies (i.e. LISP) 90 by using using BGP to distribute either a single or a set of locators 91 attached to each entry in the BGP table. Based upon this locater 92 information (the BGP Remote-Next-Hop) an overlay tunnel can be 93 utilized and created. This overlay tunnel could be any type of IPv4- 94 in-IPv4, IPv6-in-IPv4, IPv4-in-IPv6 or IPv6-in-IPv6, 96 If a recipient node has no awareness or does not understand the BGP 97 Remote-Next-Hop attribute then traditional BGP routing can be used as 98 fallback mechanism. If the recipient node does understand the BGP 99 Remote-Next-Hop attribute, then an overlay tunnel could be created 100 i.e a LISP or IPoGRE tunnel. 102 In addition, existing BGP security mechanisms can be used to verify 103 the correctness of the BGP update including the validity of the BGP 104 Remote-Next-Hop attribute. This will make sure that recipients of 105 the BGP NLRI update which understand BGP Remote-Next-Hop, are not by 106 accident tunneling to a malicious intermediate hop instead of the 107 rightful BGP end-point. 109 This note is defining the attribute for usage on Inter-AS and 110 Intra-AS environments. 112 Note that the Address Family (AF) of the NLRI exchanged is intended 113 to be independent of the Address Family of the BGP Remote-Next-Hop 114 attribute; hence the BGP Remote-Next-Hop attribute can be used within 115 and between AF environments. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 1.2. Option Format: BGP Remote-Next-Hop 125 1.2.1. BGP Option Type 127 Optional Transitive 129 1.2.2. Option Format 131 0 1 132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Attr. Flags |Attr. Type Code| 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | BGP Remote-Next-Hop Attribute | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Bit 0: Set to 1 (Optional Attribute); 141 Bit 1: Set to 1 (Transitional Attribute); 143 Bit 2: Partial bit of the attribute; 145 Depending on the size and entries within the BGP Remote-Next-Hop the 146 attribute may be complete (set to 0) or partial (set to 1); 148 Bit 3: Extended Length bit; 150 Set to 0 if non-extended; 152 Set to 1 if Extended length; 154 Bit 4 to 7 Set to 0; 156 Bit 8 to 15: Set to BGP Remote-Next-Hop attribute. Value to be 157 defined by IANA; 159 1.2.3. Remote-Next-Hop Attribute Format 161 The general format of this attribute describes the structure of the 162 BGP Remote-Next-Hop attribute. Each attribute address family MUST be 163 carried in a different Remote-Next-Hop container. (For example IPv4 164 and IPv6 will each need their own container) 166 Each attribute can cary multiple BGP Remote-Next-Hop addresses. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Address Family | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 | BGP Remote-Next-Hop | 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 The coding mentioned here is Hexadecimals. 180 If Address Family is set to 0 then it are IPv4 addresses. 182 If Address Family is set to 1 then it are IPv6 addresses. 184 Other values are reserved for the future purposes. 186 The length field is encoded in number of Octets. 188 BGP Remote-Next-Hop: the BGP Remote-Next-Hop addresses. 190 1.3. Usage Guidelines 192 This section provides a short overview of some use-case scenarios for 193 the BGP Remote-Next-Hop attribute. The usage of the BGP Remote-Next- 194 Hop attribute is not limited to the examples discussed in this 195 section. 197 1.3.1. Networks that do NOT support BGP Next-Hop-Attribute 199 If a device does not support this attribute, then due to the Optional 200 Transitive BGP character of this attribute will result that 201 traditional routing is utilized with all the benefits and drawbacks. 203 1.3.2. Multi-homing for IPv6 205 When an IPv6 network is multi-homed towards the Internet, then it may 206 be assigned with more than a single prefix. While the aspiration for 207 these different assignments is to reduce the size of the Global 208 Internet Routing table, it also results in well known resiliency 209 issues discussed in a few IETF Working groups (if attribute idea gets 210 accepted by WG, references will be added). 212 The BGP Remote-Next-Hop attribute is providing a technology to glue 213 these assigned IPv6 prefixes together and avoid some of the well 214 known resiliency issues. 216 So, how does this concept work? 218 Assume you have a Node (=Source-Node) on Network (=Source-Network) 219 and you would like to send something to your peer (Destination-Node) 220 which is a device in Network (Destination-Network). With traditional 221 routing a destination lookup is done, and forwarded each hop between 222 Source-Node and Destination-node. 224 What the attribute BGP Remote-Next-Hop provides is that when the 225 Source-Node sends a packet to the Destination-Node it can be 226 specially handled by the Source-Network edge-router. This device 227 will look at the destination address of the packet, and check the BGP 228 Remote-Next-Hop attribute (assuming that the edge-node supports that 229 idea). That lookup will allow a device understanding the attribute, 230 to select or create a tunnel towards the destination. 232 Using this will result in having organizations built Internet 233 overlays. 235 1.3.3. Mapping Technology to compliment LISP 237 LISP, the Locator ID Split protocol, makes usage of a mapping 238 technology to build up the tunnels to accommodate LISP. What this 239 BGP Remote-Next-Hop attribute is providing is that it provides a 240 mechanism to distribute tunnel end-points using existing BGP 241 infrastructure without the need of anybody requiring to enable it. 242 As result it will be ship in the night from both BGP as LISP 243 perspective. 245 1.3.4. Network Overlay Infrastructure 247 With the BGP Remote-Next-Hop feature it is possible to build and 248 create an overlay tunneled network. By using this attribute, it is 249 possible to have individual (Internet) Networks create sessions 250 between them and make sure that the Internet and serviceability 251 elements are kept correctly. 253 1.3.5. Reduction of the Routing Forwarding Information Base 255 Right now there are about 50.000 Autonomous Systems distributed, 256 which is way less as the useful entries in the existing FIB. The 257 usage of double recursive reduction has as result that even if the 258 routing table stays equal size, that the FIB (Traditionally ASIC 259 Based Forwarding Table) when everybody is using this technology is 260 reduced. ( We would go from 400K entries to 50k entries in the FIB). 262 2. IANA Considerations 264 This memo asks the IANA for a new BGP Attribute assignment. 266 3. Security Considerations 268 This technology could be used as technology as man in the middle 269 attack, however with existing RPKI validation for BGP that risk is 270 reduced. 272 Additional risks are still to be analysed by the working group and 273 feedbacck received on the draft 275 3.1. Privacy Considerations 277 This proposal could introduce privacy issues, however with BGP 278 security mechanisms in place they are removed. 280 4. Acknowledgements 282 To be completed 284 5. Change Log 286 Initial Version: 16 May 2012 288 6. References 290 6.1. Normative References 292 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 293 September 1981. 295 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 296 RFC 792, September 1981. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 302 (IPv6) Specification", RFC 2460, December 1998. 304 6.2. Informative References 306 [RFC6227] Li, T., "Design Goals for Scalable Internet Routing", 307 RFC 6227, May 2011. 309 Authors' Addresses 311 Gunter Van de Velde 312 Cisco Systems 313 De Kleetlaan 6a 314 Diegem 1831 315 Belgium 317 Phone: +32 2704 5473 318 Email: gvandeve@cisco.com 320 Keyur Patel 321 Cisco Systems 322 170 W. Tasman Drive 323 San Jose, CA 95124 95134 324 USA 326 Phone: +32 2704 5473 327 Email: keyupate@cisco.com