idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 186 has weird spacing: '...tribute and i...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 17, 2014) is 3714 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) == Missing Reference: 'RFC2003' is mentioned on line 170, but not defined == Missing Reference: 'VXLAN' is mentioned on line 233, but not defined == Missing Reference: 'NVGRE' is mentioned on line 274, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 201, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 201, but not defined == Unused Reference: 'RFC6459' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'I-D.matsushima-stateless-uplane-vepc' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 498, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Downref: Normative reference to an Informational RFC: RFC 6459 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-04 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-02 == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-01 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-02 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR G. Van de Velde 3 Internet-Draft K. Patel 4 Intended status: Standards Track D. Rao 5 Expires: July 21, 2014 Cisco Systems 6 R. Raszuk 7 NTT MCL Inc. 8 R. Bush 9 Internet Initiative Japan 10 January 17, 2014 12 BGP Remote-Next-Hop 13 draft-vandevelde-idr-remote-next-hop-05 15 Abstract 17 The BGP Remote-Next-Hop is a new optional transitive attribute 18 intended to facilitate automatic tunneling across an AS on a per 19 address family basis. The attribute carries one or more tunnel end- 20 points for a NLRI. Additionally, tunnel encapsulation information is 21 communicated to successfully setup these tunnels. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 21, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 60 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 4 62 4.1. Encapsulation sub-TLVs for virtual network overlays . . . 5 63 4.1.1. Encapsulation sub-TLV for VXLAN . . . . . . . . . . . 6 64 4.1.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . 7 65 4.1.3. Encapsulation sub-TLV for GTP . . . . . . . . . . . . 8 66 5. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Stateless user-plane architecture for virtualized EPC 68 (vEPC) . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . . 8 70 5.3. Dynamic Network Overlay Infrastructure . . . . . . . . . 9 71 5.4. The Tunnel end-point is NOT the originating BGP speaker . 9 72 5.5. Networks that do not support BGP Remote-Next-Hop 73 attribute . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.6. Networks that do support BGP Remote-Next-Hop attribute . 9 75 6. BGP Remote-Next-Hop Community . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8.1. Protecting the validity of the BGP Remote-Next-Hop 79 attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 12.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 91 end-point encapsulation information between two BGP speakers for a 92 single tunnel. It assumes that the exchanged tunnel endpoint is the 93 NLRI. 95 This document defines a new BGP transitive attribute known as a 96 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage which 97 removes the assumption of both a single tunel and that the exchanged 98 NLRI is the tunnel endpoint. 100 The tunnel endpoint information and the tunnel encapsulation 101 information is carried within a Remote-Next-Hop BGP attribute. This 102 attribute can be added to any BGP NLRI. This way the Address Family 103 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 104 family defined in [RFC5512]. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 110 be interpreted as described in [RFC2119] only when they appear in all 111 upper case. They may also appear in lower or mixed case as English 112 words, without any normative meaning. 114 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop attribute 116 The Tunnel Encapsulation attribute [RFC5512] is based on the 117 principle that the tunnel end-point is the BGP speaker originating 118 the update and is inserted as the NLRI in the exchange, with the 119 consequence that it is impossible to set the endpoint to an arbitrary 120 address. It is also assumed that there is only a single tunnel 121 between endpoints. 123 There are use cases where it is desired that the tunnel end-point 124 address should be a different address, or set of addresses, than the 125 originating BGP speaker. It is also useful to be able to signal 126 different encapsulation parameters for different prefixes with the 127 same remote tunnel end-point. The BGP Remote-Next-Hop attribute 128 provides the ability to have one or more different tunnel end-point 129 addresses from IPv4, IPv6 and/or other address-families, and be able 130 to signal next-hop encapsulation parameters along with any prefix. 132 The sub-TLVs from the Tunnel Encapsulation Attribute [RFC5512] are 133 reused for the BGP Next-Hop-Attribute. 135 Due to the intrinsic nature of both attributes, the tunnel 136 encapsulation end-point assumes that the tunnel end-point is both the 137 NLRI exchanged and the originating router, while the BGP Remote-Next- 138 Hop attribute is inserted for an exchanged NLRI by adding a set of 139 tunnel end-points and hence these two attributes are mutually 140 exclusive. 142 4. BGP Remote-Next-Hop attribute TLV Format 144 This attribute is an optional transitive attribute [RFC1771]. 146 The BGP Remote-Next-Hop attribute is is composed of a set of Type- 147 Length-Value (TLV) encodings. The type code of the attribute is 148 (IANA to assign). Each TLV contains information corresponding to a 149 particular tunnel technology and tunnel end-point address. The TLV 150 is structured as follows: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Tunnel Type (2 Octets) | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Addr len | Tunnel Address (IPv4 or IPv6) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | AS Number | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Tunnel Parameters | 162 ~ ~ 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Tunnel Type (2 octets): identifies the type of tunneling technology 166 being signaled. This document specifies the following types: 168 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 169 - GRE [RFC2784]: Tunnel Type = 2 170 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 172 This document also defines the following types: 173 - VXLAN: Tunnel Type = 8 174 - NVGRE: Tunnel Type = 9 175 - GTP: Tunnel Type = 10 177 Unknown types MUST be ignored and skipped upon receipt. 179 Length (2 octets): the total number of octets of the value field. 181 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 182 Address. Set to 4 bytes for an IPv4 address and 16 bytes for an 183 IPv6 address. 185 AS Number - The AS number originating the BGP Remote-Next-Hop 186 attribute and is either a 2-byte AS or 4-Byte AS number 188 Tunnel Parameter - (variable): comprised of multiple sub-TLVs. 189 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 190 length, and zero or more octets of value. The sub-TLV definitions 191 and the sub-TLV data are described in depth in [RFC5512]. 193 4.1. Encapsulation sub-TLVs for virtual network overlays 195 A VN-ID may need to be signaled along with the encapsulation types 196 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 197 when present in the encapsulation sub-TLV for an overlay 198 encapsulation, MUST be processed by a receiving device if it is 199 capable of understanding it. The details regarding how such a 200 signaled VN-ID is processed and used is defined in specifications 201 such as [IPVPN-overlay] and [EVPN-overlay]. 203 4.1.1. Encapsulation sub-TLV for VXLAN 205 This document defines a new encapsulation sub-TLV format, defined in 206 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 207 following is the structure of the value field in the encapsulation 208 sub-TLV: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | MAC Address (4 Octets) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | MAC Address (2 Octets) | Reserved | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 V: When set to 1, it indicates that a valid VN-ID is present in the 221 encapsulation sub-TLV. 222 M: When set to 1, it indicates that a valid MAC Address is present 223 in the encapsulation sub-TLV. 224 R: The remaining bits in the 8-bit flags field are reserved for 225 further use. They MUST be set to 0 on transmit and MUST be ignored 226 on receipt. 228 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 229 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 230 ignored on receipt. 232 The VN-ID value is filled in the VNI field in the VXLAN packet 233 header as defined in [VXLAN]. 235 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit 236 is set. If the 'M' flag is not set, it SHOULD set to all zeroes and 237 MUST be ignored on receipt. 239 The MAC address is local to the device advertising the route, and 240 should be included as the destination MAC address in the inner 241 Ethernet header immediately following the outer VXLAN header, in 242 the packets destined to the advertiser. 244 4.1.2. Encapsulation sub-TLV for NVGRE 246 This document defines a new encapsulation sub-TLV format, defined in 247 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 248 following is the structure of the value field in the encapsulation 249 sub-TLV: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MAC Address (4 Octets) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | MAC Address (2 Octets) | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 V: When set to 1, it indicates that a valid VN-ID is present in the 262 encapsulation sub-TLV. 263 M: When set to 1, it indicates that a valid MAC Address is present 264 in the encapsulation sub-TLV. 265 R: The remaining bits in the 8-bit flags field are reserved for 266 further use. They MUST be set to 0 on transmit and MUST be ignored 267 on receipt. 269 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 270 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 271 ignored on receipt. 273 The VN-ID value is filled in the VSID field in the NVGRE packet 274 header as defined in [NVGRE]. 276 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is 277 set. If the 'M' flag is not set, it SHOULD set to all zeroes and 278 MUST be ignored on receipt. 280 The MAC address is local to the device advertising the route, and 281 should be included as the destination MAC address in the inner 282 Ethernet header immediately following the outer NVGRE header, in 283 the packets destined to 284 the advertiser. 286 4.1.3. Encapsulation sub-TLV for GTP 288 This document defines a new encapsulation sub-TLV format, defined in 289 [RFC5512], for GTP tunnels. When the tunnel type is GTP, the 290 following is the structure of the value field in the encapsulation 291 sub-TLV: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TEID (4 Octets) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 TEID: Tunnel endpoint identifier (TEID)[RFC6459]is a 32-bit(4-octet) 300 field used to multiplex different connections in the same GTP 301 tunnel. 303 5. Use Case scenarios 305 This section provides a short overview of some use-cases for the BGP 306 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 307 limited to the examples in this section. 309 5.1. Stateless user-plane architecture for virtualized EPC (vEPC) 311 The full usage case of BGP remote-next-hop regarding vEPC can be 312 found in [vEPC], while [RFC6459]documents IPv6 in 3GPP EPS. 314 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 315 mobile system for LTE and -advanced in their Release-8 specification 316 and beyond. Operators are now deploying EPC for LTE services and 317 encounter rapid LTE traffic growth. There are various activities to 318 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 319 The concept is similar that traffic of OTT (Over The Top) application 320 is offloaded at entity that is closer to the mobile node (ex. eNodeB 321 or closer anchor). 323 5.2. Multi-homing for IPv6 325 When an end-user IPv6 network is multi-homed to the Internet, it may 326 be assigned more than a single prefix originated by various upstream 327 ASs. Each AS prefers to only announce a supernet of all its assigned 328 IPv6 prefixes, unlike IPv4 where the AS announced the end-users 329 assigned prefix. The goal of this BGP policy behaviour is to keep 330 the number of entries in the IPv6 global BGP table to a minimum, it 331 also it also results in well known resiliency improvements. 333 For example, if an end-user IPv6 is peering with 2 different Service 334 providers AS1 and AS2. In this case the IPv6 end-user will have at 335 least one prefix assigned from each of these service providers. The 336 devices at the IPv6 end-user will each receive an address from these 337 prefixes. The devices will in most cases, when building IPv6 338 sessions (TCP, etc...), do so with only a single IPv6 address. The 339 decision which IPv6 address the device will use is documented in 340 [RFC3484]. 342 If one of the links between the end-user and one the neighboring AS's 343 fails, a consequence will be that a set of sessions need to be reset, 344 or that a section of the end-user network becomes unreachable. 346 With usage of the BGP-remote-Next-Hop attribute the service provider 347 can tunnel that packet towards an alternate BGP Remote-Next-Hop at 348 the end-users alternate provider and restore the network connectivity 349 even though the local link towards the end-user is broken. 351 5.3. Dynamic Network Overlay Infrastructure 353 The BGP Remote-Next-Hop extension allows signaling tunnel 354 encapsulations needed to build and dynamically create an overlay 355 tunneled network with traffic isolation and virtual private networks. 357 5.4. The Tunnel end-point is NOT the originating BGP speaker 359 Note that, in each network environment, the originating router is the 360 preferred tunnel end-point server. It may be that the network 361 administrator has deployed an independent set of tunnel end-point 362 servers across their network, which may or may not speak BGP. The 363 BGP Remote-Next-Hop attribute provides the ability to signal this via 364 BGP. 366 5.5. Networks that do not support BGP Remote-Next-Hop attribute 368 If a device does not support this attribute, and receives this 369 attribute, then normal NLRI BGP forwarding is used as the attribute 370 is optional and transitive. 372 5.6. Networks that do support BGP Remote-Next-Hop attribute 374 If a BGP speaker does understand this attribute, and receives this 375 attribute, then the BGP speaker MAY, by configuration, skip use or 376 not use the information within this attribute. 378 6. BGP Remote-Next-Hop Community 380 place-holder for an BGP extension to signal valid prefixes allowed to 381 be considered as tunnel end-points. To be completed. 383 7. IANA Considerations 385 This memo asks the IANA for a new BGP attribute assignment for the 386 BGP Remote-Next-Hop attribute. 388 This memo also asks the IANA to reserve the following new Tunnel 389 Types for signaling VXLAN and NVGRE encapsulations. 391 VXLAN: Tunnel Type = 8 393 NVGRE: Tunnel Type = 9 395 GTP: Tunnel Type = 10 397 8. Security Considerations 399 This technology could be used as technology as man in the middle 400 attack, however with existing RPKI validation for BGP that risk is 401 reduced. 403 The distribution of Tunnel end-point address information can result 404 in potential DoS attacks if the information is sent by malicious 405 organisations. Therefore is it strongly recommended to install 406 traffic filters, IDSs and IPSs at the perimeter of the tunneled 407 network infrastructure. 409 8.1. Protecting the validity of the BGP Remote-Next-Hop attribute 411 It is possible to inject a rogue BGP Remote-Next-Hop attribute to an 412 NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this 413 type of MITM attack, it is strongly recommended to use a technology a 414 mechanism to verify that for NLRI it is the expected BGP Remote-Next- 415 Hop. We anticipate that this can be done with an expansion of RPKI- 416 Based origin validation, see [I-D.ietf-sidr-pfx-validate]. 418 This does not avoid the fact that rogue AS numbers may be inserted or 419 injected into the AS-Path. To achieve protection against that threat 420 BGP Path Validation should be used, see 421 [I-D.ietf-sidr-bgpsec-overview]. 423 9. Privacy Considerations 425 This proposal may introduce privacy issues, however with BGP security 426 mechanisms in place they should be prevented. 428 10. Acknowledgements 430 The authors would like to thanks Satoru Matsushima, Ryuji Wakikawa 431 and Miya Kohno for their usefull vEPC discussions 433 11. Change Log 435 Initial Version: 16 May 2012 437 Hacked for -01: 17 July 2012 439 Hacked for -05: 07 January 2014 441 12. References 443 12.1. Normative References 445 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 446 (BGP-4)", RFC 1771, March 1995. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 452 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 453 March 2000. 455 [RFC3484] Draves, R., "Default Address Selection for Internet 456 Protocol version 6 (IPv6)", RFC 3484, February 2003. 458 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 459 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 461 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 462 for IPv6 Hosts and Routers", RFC 4213, October 2005. 464 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 465 Subsequent Address Family Identifier (SAFI) and the BGP 466 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 468 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 469 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 470 Partnership Project (3GPP) Evolved Packet System (EPS)", 471 RFC 6459, January 2012. 473 12.2. Informative References 475 [I-D.ietf-sidr-bgpsec-overview] 476 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 477 draft-ietf-sidr-bgpsec-overview-04 (work in progress), 478 December 2013. 480 [I-D.ietf-sidr-pfx-validate] 481 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 482 Austein, "BGP Prefix Origin Validation", draft-ietf-sidr- 483 pfx-validate-10 (work in progress), October 2012. 485 [I-D.mahalingam-dutt-dcops-vxlan] 486 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 487 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 488 Framework for Overlaying Virtualized Layer 2 Networks over 489 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02 490 (work in progress), August 2012. 492 [I-D.matsushima-stateless-uplane-vepc] 493 Matsushima, S. and R. Wakikawa, "Stateless user-plane 494 architecture for virtualized EPC (vEPC)", draft- 495 matsushima-stateless-uplane-vepc-01 (work in progress), 496 July 2013. 498 [I-D.sridharan-virtualization-nvgre] 499 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 500 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 501 and C. Tumuluri, "NVGRE: Network Virtualization using 502 Generic Routing Encapsulation", draft-sridharan- 503 virtualization-nvgre-02 (work in progress), February 2013. 505 Authors' Addresses 507 Gunter Van de Velde 508 Cisco Systems 509 De Kleetlaan 6a 510 Diegem 1831 511 Belgium 513 Phone: +32 2704 5473 514 Email: gvandeve@cisco.com 515 Keyur Patel 516 Cisco Systems 517 170 W. Tasman Drive 518 San Jose, CA 95124 95134 519 USA 521 Email: keyupate@cisco.com 523 Dhananjaya Rao 524 Cisco Systems 525 170 W. Tasman Drive 526 San Jose, CA 95124 95134 527 USA 529 Email: dhrao@cisco.com 531 Robert Raszuk 532 NTT MCL Inc. 533 101 S Ellsworth Avenue Suite 350 534 San Mateo, CA 94401 535 US 537 Email: robert@raszuk.net 539 Randy Bush 540 Internet Initiative Japan 541 5147 Crystal Springs 542 Bainbridge Island, Washington 98110 543 US 545 Email: randy@psg.com