idnits 2.17.1 draft-yong-intarea-inter-sites-over-tunnels-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2731 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC792' is defined on line 468, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-03 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- No information found for draft-dunbar-interarea-private-networks-over-thinCPE - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Yong 2 Internet-Draft L. Dunbar 3 Intended status: BCP Huawei 4 T. Herbert 5 Facebook 7 Expires: April 2017 October 31, 2016 9 Interconnecting Network Sites by IP Tunnels 10 draft-yong-intarea-inter-sites-over-tunnels-00.txt 12 Abstract 14 This document specifies use of a set of IP tunnels to interconnect 15 multiple network sites over IP backbone networks. The interconnected 16 network sites form 'virtual' private network(s). The networks at any 17 of those sites can be Layer 2 domains or/and Layer 3 subnets. The IP 18 backbone networks that the tunnels traverse through can be IPv4 or 19 IPv6. This document describes the special property (or features) 20 that those IP tunnels need to have in order to interconnect multiple 21 sites as if those sites are directly connected by wires. 23 Status of This Document 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 34 months and may be updated, replaced, or obsoleted by other documents 35 at any 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 April 31, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction...................................................3 58 1.1. Motivation of sites interconnection by IP tunnels.........3 59 2. Terminology....................................................4 60 2.1. Requirements language.....................................4 61 2.2. Terms defined in this document............................5 62 3. Sites interconnection solution architecture....................5 63 4. Key properties of sites interconnection over IP tunnels........7 64 4.1. Network sites interconnection properties..................7 65 4.2. Tunnel transport properties for sites interconnection.....8 66 5. Site traffic encapsulation.....................................9 67 6. Tunneling multicast and broadcast traffic......................9 68 7. Tunnel transport over IP.......................................9 69 7.1. Tunnel transport mode.....................................9 70 7.2. MTU and fragmentation....................................10 71 7.3. Checksum.................................................10 72 7.4. Congestion management....................................10 73 7.4.1. Congestion detection................................10 74 7.4.2. Congestion notification.............................10 75 7.4.3. Tunnel ingress traffic control......................10 76 7.5. Tunnel traffic hop count and DSCP value setting..........10 77 7.6. Middle box considerations................................10 78 8. Sites interconnection security................................10 79 9. Tunnel configuration..........................................11 80 10. Tunnel tools.................................................11 81 11. Operational considerations...................................11 82 12. IANA considerations..........................................11 83 13. Security considerations......................................11 84 14. References...................................................11 85 14.1. Normative References....................................11 86 14.2. Informative Reference...................................11 87 15. Authors' Addresses...........................................12 89 1. Introduction 91 This document specifies use of a set of IP tunnels to interconnect 92 multiple network sites over IP backbone networks. The networks at 93 any of those sites can be Layer 2 domains or Layer 3 subnets; IP 94 backbone networks that tunnels traverse can be IPv4 or IPv6. This 95 document describes the properties (or features) that IP tunnels need 96 to have in order to interconnect multiple sites as if those sites 97 are directly connected by wires. 99 An IP tunnel in this document is identified by a pair of IP 100 addresses (IPv4 or IPv6) that IP backbone networks can reach or the 101 IP addresses plus a pair of UDP ports; one address per each tunnel 102 endpoint. Tunnel ingress receives network traffic from its site (or 103 access ports) and will encapsulate the traffic with an outer header 104 whose destination and source address are the tunnel's two end points 105 respectively. Tunnel egress receives IP packets from the backbone 106 network, decapsulates the IP packets, and forwards decapsulated 107 traffic toward its site (or an access port). 109 Section 1.1 describes the motivation of this specification. Section 110 3 describes the solution architecture for sites interconnection by 111 IP tunnels. Section 4 specifies the sites interconnection 112 requirements for the IP tunnels. The rest of Sections describe Site 113 Interconnection Tunnel (SITE) solution. Section 11 describes 114 operational considerations for sites interconnection over IP tunnels. 116 Note: The site interconnection policy configuration and the prefix 117 routing within a site and across sites are outside the scope of this 118 document. 120 1.1. Motivation of sites interconnection by IP tunnels 122 Tunneling technology has being widely used in IP networks. For 123 examples: transporting packets in one address family (e.g. IPv6) 124 over a network of different address family (e.g. IPv4) [RFC7059]; 125 establishing a direct logical "link" for traffic engineering; 126 traffic security over the Internet (e.g. IPsec tunnel [RFC5996] 127 [RFC3884]); or Location and Identifier Separation application (LISP) 128 [RFC6830]. 130 Provider based L2VPN and L3VPN solutions [RFC4762] [RFC4364] use 131 MPLS LSP tunnel technology to interconnect provider edge devices, 132 i.e., Provider Edge (PE). In these solutions, PEs are part of 133 provider backbone networks that implement the VPN solutions. For a 134 customer to get a provider based VPN service, each customer site 135 must attach to at least one of the PEs in the provider backbone 136 networks, this attachment is called attachment circuit (AC) [RFC4664] 137 [RFC4364]. 139 Today, a company can use IPSec tunnels [RFC5996][RFC3884] to 140 interconnect its IP subnets at different sites over the Internet if 141 the company has an experienced operator to configure its site 142 networks and the devices that support the IPsec tunnel capability. 143 To achieve this, each site needs to have at least one device 144 attaching to an IP backbone network and have at least one public IP 145 address that the IP backbone networks can reach to. As a result, the 146 interconnected sites form one "virtual" private network among the 147 sites. In this case, an ISP provider (i.e. IP backbone provider) 148 does not provide the sites interconnection service to the company 149 although it carries the IPsec tunnel traffic; in other words, the 150 ISP provider only provides Internet access service to each site. As 151 a result, there is no guaranteed QoS between a pair of sites, which 152 is the difference from provider based VPN solutions. 154 Sites interconnection by IP tunnels is attractive to some companies 155 that operate at multiple locations. Some companies wish to do it but 156 do not have such an experienced operator to construct/configure site 157 networks and tunnels to achieve this. A vendor may make a product to 158 achieve this and sell to these companies. The product includes a 159 site gateway device or component (called S-GW in this document) and 160 software to allow a customer to specify their site interconnection 161 requirements including sites interconnection policies. The software 162 will manage the configuration of the S-GWs at multiple locations; 163 furthermore the software can automate the processes from client 164 specifying the sites interconnection to the sites interconnection 165 completion. Section 3 highlights this solution architecture. 167 A SP provider may use this product and integrate it with its 168 provider based VPN solution [RFC4364][RFC4762][RFC7432] to provide 169 agile VPN services to its customers. [Dunbar] 171 2. Terminology 173 2.1. Requirements language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2.2. Terms defined in this document 181 Site: A place that contains switches, routers, services, appliances 182 and these devices are configured to form L2 domain (s) or L3 domain. 183 For examples, an Enterprise company data center, a college campus 184 network center. 186 SITE: Site Interconnection Tunnel Protocol Solution 188 More coming 190 3. Sites interconnection solution architecture 192 .-.-.-.-.-,-.-,-.-.-,-. 193 / Site Operator \ 194 { | } 195 . +-----V----+ . 196 ( |Inter-con | ) 197 { | Portal | } 198 . +----------+ . 199 % | * 200 $ +---------+ $ 201 # | Site | # 202 ! |Inter-con| ! 203 % | App | % 204 $ +----+----+ & 205 ! / \ ! 206 ! / \ SIC-Ch ! 207 ,.............., !+------+ +---------+! ,............, 208 . . / \ . . 209 . +-/--+ IP tunnel +--\-+ . 210 . Site A |Site+====================+Site| Site B . 211 . network |GW | |GW | network . 212 . +----+\ IP Backbone +----+ . 213 . . $ \ $ . . 214 ,.............., ! \ ! ,............, 215 ( V Web Traffic ) 216 ' . 217 $,-,-,-,-,-,-,-,-,-,-,-$ 219 Figure 1 : Sites Interconnection Solution Architecture View 221 Figure 1 illustrates the solution architecture of sites 222 interconnection. The architecture contains the following components: 224 o Site Gateway (S-GW): A router and/or switch device/component. It 225 can be configured to perform routing/forwarding function at the 226 site. S-GW attaches to an IP backbone network and support a 227 tunnel capability specified in this document. S-GW can be 228 configured with one IP address to be used as tunnel end point for 229 all tunnels to other sites or be configured with one IP address 230 per a tunnel to a remote site. 232 o Sites Interconnection Controller (SIC): A software component that 233 controls/manages individual S-GWs via a SIC channel. It receives 234 a sites interconnection request from the SIP; processes it, and 235 sends the configuration data to individual S-GWs via SIC channel. 237 o Sites Interconnection Portal: A software with GUI interface to 238 allow site operator to specify its sites interconnection 239 requirement including sites interconnection policy. The same 240 portal can be used for the site operator to specify the site 241 Internet access policies. 243 o SIC Channel: a communication channel between S-GW and SIC over IP 244 network. It could be a TCP application with security capability. 245 The channel is used for SIC to send S-GW configuration data and 246 get the PM data from S-GW. It may be used for dynamic routing 247 purpose among the sites; in this case, SIC gets the prefix 248 information from the S-GW at a site, and send the information to 249 the S-GWs at other sites where the S-GW will distribute the 250 information to the site. 252 o IP tunnel: A tunnel exists between a pair of S-GWs. The tunnel 253 end point as an interface on a S-GW receives network traffic and 254 encapsulate the traffic with an outer header whose Destination 255 and Source address are the tunnel's two end points respectively. 256 Tunnel egress receives IP packets from the IP backbone network, 257 decapsulates the IP packets, and forwards decapsulated packets 258 toward its site (or one access port(s)). IP tunnel is 259 unidirectional, two sites interconnection requires two tunnels, 260 one for each direction. Two tunnels may traverse different paths 261 in backbone network. 263 In this architecture, each site uses its S-GW to attach to IP 264 backbone network, which implies that the site traffic may go to the 265 Internet via the S-GW. For security and performance reason, it is 266 RECOMMENDED to use different public IP addresses for the Internet 267 access and the tunnel end point of sites interconnection. It is 268 possible to use more than one S-GW at a site for sites 269 interconnection. 271 In this architecture, a site may have L2 domains, L3 subnets, or 272 TRILL networks. However, the interconnected site networks MUST have 273 the same type (see Section 3.1). 275 Note: This document will not specify the whole solution for this 276 architecture. It only specifies the tunnel end point functions at a 277 S-GW and tunnel end point configuration at the S-GW. Other functions 278 in this solution architecture will be addressed in other documents. 280 4. Key properties of sites interconnection over IP tunnels 282 This section only lists the requirements for sites interconnection 283 over IP tunnels. The entire solution architecture requirements are 284 beyond the scope of this document. 286 4.1. Network sites interconnection properties 288 1. A site in this context may have a single network or multiple 289 networks. For single network case, the network may be an L2 290 domain, L3 subnets, or a TRILL network. For the case of multiple 291 networks, each network may be an L2 domain or L3 subnets and 292 individual network traffic is segregated within the site 293 including on the S-GW. Sites interconnection MUST NOT 294 interconnect the networks at two sites that have different type. 295 For example, one is L3 subnet, another is L2 domain. In the case 296 of multiple networks at a site, sites interconnection MUST 297 support individual networks at the site to be connected to the 298 same type of networks that reside in either a remote site or 299 different remote sites. 301 2. The S-GW MUST support site Internet access. The traffic to the 302 Internet and the traffic to a remote site SHOULD be segregated by 303 different S-GW physical ports or different IP addresses to avoid 304 DDoS attack [RFC4732]. 306 3. Tunnels for sites interconnection MUST secure site traffic over 307 the IP backbone network. 309 4. Tunnels for sites interconnection MUST segregate the site traffic 310 from different networks. 312 5. Sites interconnection topology may be mesh or hub-spoke. 314 6. Tunnel for sites interconnection MUST be able to detect 315 congestion on the path of IP backbone network and MUST stop some 316 site traffic based on the operator specified policy. (stop some 317 traffic on both directions or congestion direction?). Early 318 dropping traffic will help site applications to take an action. 319 S-GW MUST reports the congestion status to site interconnection 320 app (SIA). 322 7. A site can be configured with two S-GWs for redundant and/or 323 transport capacity. The remote S-GW MUST be able to support load 324 balance tunnel traffic. A S-GW at a site MUST NOT forward 325 incoming traffic from IP backbone to another S-GW at the site, 326 which creates the loop. 328 8. Site network traffic may be unicast, mcast, or bcast(L2) traffic. 329 Sites interconnection solution MUST be able to carry unicast, 330 mcast, bcast traffic over tunnels. 332 9. Site network traffic may be control plane packets such as IBGP 333 (ISIS?) or control packets such as ICMP, ARP. Tunnel SHOULD be 334 able to carry control plane or control packets according to 335 operator specified site interconnection policy. In default, a 336 tunnel MUST NOT carry control plane packets over the tunnel. 338 10.Other? 340 4.2. Tunnel transport properties for sites interconnection 342 This section lists tunnel transport requirements over IP backbone 343 networks for sites interconnection application. 345 1. Tunnel type (tunnel mode, or transport mode, or both) 347 2. IP backbone network can be IPv4 or IPv6 network. A tunnel MUST be 348 able to run over an IPv4 or IPv6 network. 350 3. Tunnel solution MUST meet IP [RFC791] [RFC2460] and UDP 351 application requirements [RFC5405bis] 353 4. Tunnel MTU and Fragmentation [JOE]. Tunnel SHOULD avoid tunnel 354 traffic to be fragmented on IP backbone networks. 356 5. Tunnel solution supports configuration option to turn off traffic 357 encryption function. 359 6. Tunnel solution supports congestion control upon detecting 360 congestion condition on the tunnel path (use circuit breaker, 361 packet drop/report at ingress, notification to source). 363 7. Tunnel solution MUST map site traffic QoS to proper DSCP value on 364 tunnel IP packets based on operation specified policy. 366 8. Tunnel solution SHOULD be able to monitor the inter-sites 367 connectivity and report the status. 369 9. Tunnel solution SHOULD support some tools for sites 370 interconnection operator such as tunnel path trace, ping, 371 tunnel's throughput test, etc. 373 10.ICMP handling (from Internet or from remote tunnel end-point). 375 11.Others, Hop count for tunnel traffic, middle box considerations, 376 etc. 378 5. Site traffic encapsulation 380 GRE-in-UDP w/DTLS [GRE-in-UDP] or GUE [GUE]: the reason is: 382 o It can run over the Internet (Ipv4 and Ipv6) 384 o It runs as UDP application, ECMP advantage, and middle box 385 traversal benefit. 387 o Encapsulate different types of traffic 389 o Ability to support fragmentation 391 o Security/encryption capability 393 o Support traffic segregation 395 Like to hear other's opinions on encapsulation protocol choices. 397 6. Tunneling multicast and broadcast traffic 399 7. Tunnel transport over IP 401 7.1. Tunnel transport mode 403 Tunnel mode or transport mode or both.[RFC3884] 405 7.2. MTU and fragmentation 407 Intarea-tunnels draft or GUE-extension draft 409 7.3. Checksum 411 Tunnel solution MUST implement the checksum specification for 412 default GRE-in-UDP tunnel in [GRE-in-UDP]. 414 7.4. Congestion management 416 More than likely, a site operator has no way to control transport 417 path resource in IP backbone networks for sites interconnection. 418 Tunnel packets are treated as regular IP packets and traverse a path 419 in IP backbone networks that other IP application packets traverse 420 as well. Congestion may happen due to "ship-in-night" situation. IP 421 backbone network uses explicitly congestion notification (ECN) 422 [RFC6040] to indicate IP applications about the network congestion. 424 Upon backbone path congestion, a tunnel for the site interconnection 425 MUST stop some traffic based on operator's interconnection policy. 426 This section specifies the tunnel congestion control mechanism. 428 7.4.1. Congestion detection 430 7.4.2. Congestion notification 432 7.4.3. Tunnel ingress traffic control 434 7.5. Tunnel traffic hop count and DSCP value setting 436 7.6. Middle box considerations 438 8. Sites interconnection security 440 For site traffic security, tunnel MUST use DTLS to encrypt site 441 traffic, i.e., use GRE-in-UDP w/ DTLS. This feature MAY be turned 442 off by a site operator if the site network traffic is already 443 encrypted. 445 A site operator SHOULD request a security service from IP backbone 446 provider to prevent DDoS traffic to reach the tunnel end point at a 447 S-GW of the sites. 449 9. Tunnel configuration 451 10. Tunnel tools 453 11. Operational considerations 455 12. IANA considerations 457 13. Security considerations 459 14. References 461 14.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC2119, March 1997. 466 [RFC791] DARPA, "INTERNET PROTOCOL", RFC791, September, 1981. 468 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, 469 RFC792, September 1981. 471 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 472 (IPv6) Specification", RFC 2460, December 1998. 474 [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for 475 Application Designers", draft-ietf-tsvwg-rfc5405bis, work 476 in progress. 478 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 479 Notification", RFC6040, November 2010. 481 [GRE-in-UDP] Yong, L., et al, "GRE-in-UDP Encapsulation", draft- 482 ietf-tsvwg-gre-in-udp-encap-19, work in progress. 484 [JOE] Touch, J. and Townsley, M., "IP Tunnels in the Internet 485 Architecture", draft-ietf-intarea-tunnels-03, work in 486 progress. 488 14.2. Informative Reference 490 [RFC3884] Touch, J., Eggert, L., and Wang, Y., "Use of Ipsec 491 Transport Mode for Dynamic Routing", September 2004. 493 [RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private 494 Networks (VPNs)", RFC4364, February 2006. 496 [RFC4664] Andersson, L. and Rosen, E., "Framework for Layer 2 497 Virtual Private Networks (L2VPNs)", RFC4664, September 498 2006. 500 [RFC4732] Handley, M. and Rescorla, E., "Internet Denial-of-Service 501 Considerations" RFC4732, November 2006. 503 [RFC4762] Lasserre, M. and Kompella, V.,"Virtual Private LAN Service 504 (VPLS) using Label Distribution Protocol (LDP) Signaling", 505 RFC4762, January 2007. 507 [RFC5996] Kaufman, C., et al, "Internet Key Exchange Protocol 508 Version 2 (IKEv2)", September 2010. 510 [RFC6830] Farinacci, D., et al, "The Locator/IP Separation Protocol 511 (LISP)", RFC6830, January 2013. 513 [RFC7059] Steffann, S., et al, "A comparison of IPv6-over-IPv4 514 Tunnel Mechanism", RFC7059, November 2013 516 [RFC7432] Sajassi, A., et al, "BGP MPLS-Based Ethernet VPN", 517 RFC7432, February 2015. 519 [Dunbar] Dunbar, L., Yong, L., Song, X., "Client Defined Private 520 Networks laid over Thin CEPs", draft-dunbar-interarea- 521 private-networks-over-thinCPE, work in progress. 523 [GUE] Herbert, T., Yong, L., Zia, O, "Generic UPD Encapsulation", 524 draft-ietf-nvo3-gue-05, work in progress. 526 15. Authors' Addresses 528 Lucy Yong 529 Huawei Technologies 531 Email: lucy.yong@huawei.com 533 Linda Dunbar 534 Huawei Technologies 536 Email: linda.dunbar@huawei.com 538 Tom Herbert 539 Facebook 541 Emails: tom@herbertland.com