idnits 2.17.1 draft-ietf-softwire-mesh-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1405. 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 Copyright Line does not match the current year -- 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 (September 18, 2008) is 5698 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) == Outdated reference: A later version (-03) exists of draft-ietf-softwire-encaps-ipsec-01 == Outdated reference: A later version (-05) exists of draft-ietf-softwire-encaps-safi-03 == Outdated reference: A later version (-02) exists of draft-ietf-softwire-v4nlri-v6nh-01 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-08 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-07 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-05 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-05 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet Draft Y. Cui 4 Intended Status: Standards Track X. Li 5 Expires: March 18, 2009 Tsinghua University 7 C. Metz 8 E. Rosen (Editor) 9 S. Barber 10 P. Mohapatra 11 Cisco Systems, Inc. 13 J. Scudder 14 Juniper Networks, Inc. 16 September 18, 2008 18 Softwire Mesh Framework 20 draft-ietf-softwire-mesh-framework-05.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 The Internet needs to be able to handle both IPv4 and IPv6 packets. 48 However, it is expected that some constituent networks of the 49 Internet will be "single protocol" networks. One kind of single 50 protocol network can parse only IPv4 packets and can process only 51 IPv4 routing information; another kind can parse only IPv6 packets 52 and can process only IPv6 routing information. It is nevertheless 53 required that either kind of single protocol network be able to 54 provide transit service for the "other" protocol. This is done by 55 passing the "other kind" of routing information from one edge of the 56 single protocol network to the other, and by tunneling the "other 57 kind" of data packet from one edge to the other. The tunnels are 58 known as "Softwires". This framework document explains how the 59 routing information and the data packets of one protocol are passed 60 through a single protocol network of the other protocol. The 61 document is careful to specify when this can be done with existing 62 technology, and when it requires the development of new or modified 63 technology. 65 Table of Contents 67 1 Specification of requirements ......................... 4 68 2 Introduction .......................................... 4 69 3 Scenarios of Interest ................................. 7 70 3.1 IPv6-over-IPv4 Scenario ............................... 7 71 3.2 IPv4-over-IPv6 Scenario ............................... 9 72 4 General Principles of the Solution .................... 11 73 4.1 'E-IP' and 'I-IP' ..................................... 11 74 4.2 Routing ............................................... 11 75 4.3 Tunneled Forwarding ................................... 12 76 5 Distribution of Inter-AFBR Routing Information ........ 12 77 6 Softwire Signaling .................................... 14 78 7 Choosing to Forward Through a Softwire ................ 16 79 8 Selecting a Tunneling Technology ...................... 16 80 9 Selecting the Softwire for a Given Packet ............. 17 81 10 Softwire OAM and MIBs ................................. 18 82 10.1 Operations and Maintenance (OAM) ...................... 18 83 10.2 MIBs .................................................. 19 84 11 Softwire Multicast .................................... 19 85 11.1 One-to-One Mappings ................................... 20 86 11.1.1 Using PIM in the Core ................................. 20 87 11.1.2 Using mLDP and Multicast MPLS in the Core ............. 21 88 11.2 MVPN-like Schemes ..................................... 22 89 12 Inter-AS Considerations ............................... 23 90 13 IANA Considerations ................................... 24 91 14 Security Considerations ............................... 24 92 14.1 Problem Analysis ...................................... 24 93 14.2 Non-cryptographic techniques .......................... 26 94 14.3 Cryptographic techniques .............................. 27 95 15 Acknowledgments ....................................... 28 96 16 Normative References .................................. 28 97 17 Informative References ................................ 29 98 18 Full Copyright Statement .............................. 32 99 19 Intellectual Property ................................. 33 100 1. Specification of requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Introduction 108 The routing information in any IP backbone network can be thought of 109 as being in one of two categories: "internal routing information" or 110 "external routing information". The internal routing information 111 consists of routes to the nodes that belong to the backbone, and to 112 the interfaces of those nodes. External routing information consists 113 of routes to destinations beyond the backbone, especially 114 destinations to which the backbone is not directly attached. In 115 general, BGP [RFC4271] is used to distribute external routing 116 information, and an "Interior Gateway Protocol" (IGP) such as OSPF 117 [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing 118 information. 120 Often an IP backbone will provide transit routing services for 121 packets that originate outside the backbone, and whose destinations 122 are outside the backbone. These packets enter the backbone at one of 123 its "edge routers". They are routed through the backbone to another 124 edge router, after which they leave the backbone and continue on 125 their way. The edge nodes of the backbone are often known as 126 "Provider Edge" (PE) routers. The term "ingress" (or "ingress PE") 127 refers to the router at which a packet enters the backbone, and the 128 term "egress" (or "egress PE") refers to the router at which it 129 leaves the backbone. Interior nodes are often known as "P routers". 130 Routers which are outside the backbone but directly attached to it 131 are known as "Customer Edge" (CE) routers. (This terminology is 132 taken from [RFC4364].) 134 When a packet's destination is outside the backbone, the routing 135 information which is needed within the backbone in order to route the 136 packet to the proper egress is, by definition, external routing 137 information. 139 Traditionally, the external routing information has been distributed 140 by BGP to all the routers in the backbone, not just to the edge 141 routers (i.e., not just to the ingress and egress points). Each of 142 the interior nodes has been expected to look up the packet's 143 destination address and route it towards the egress point. This is 144 known as "native forwarding": the interior nodes look into each 145 packet's header in order to match the information in the header with 146 the external routing information. 148 It is, however, possible to provide transit services without 149 requiring that all the backbone routers have the external routing 150 information. The routing information which BGP distributes to each 151 ingress router specifies the egress router for each route. The 152 ingress router can therefore "tunnel" the packet directly to the 153 egress router. "Tunneling the packet" means putting on some sort of 154 encapsulation header which will force the interior routers to forward 155 the packet to the egress router. The original packet is known as the 156 "encapsulation payload". The P routers do not look at the packet 157 header of the payload, but only at the encapsulation header. Since 158 the path to the egress router is part of the internal routing 159 information of the backbone, the interior routers then do not need to 160 know the external routing information. This is known as "tunneled 161 forwarding". Of course, before the packet can leave the egress, it 162 has to be decapsulated. 164 The scenario where the P routers do not have external routes is 165 sometimes known as a "BGP-free core". That is something of a 166 misnomer, though, since the crucial aspect of this scenario is not 167 that the interior nodes don't run BGP, but that they don't maintain 168 the external routing information. 170 In recent years, we have seen this scenario deployed to support VPN 171 services, as specified in [RFC4364]. An edge router maintains 172 multiple independent routing/addressing spaces, one for each VPN to 173 which it interfaces. However, the routing information for the VPNs 174 is not maintained by the interior routers. In most of these 175 scenarios, MPLS is used as the encapsulation mechanism for getting 176 the packets from ingress to egress. There are some deployments in 177 which an IP-based encapsulation, such as L2TPv3 (Layer 2 Transport 178 Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784] 179 is used. 181 This same technique can also be useful when the external routing 182 information consists not of VPN routes, but of "ordinary" Internet 183 routes. It can be used any time it is desired to keep external 184 routing information out of a backbone's interior nodes, or in fact 185 any time it is desired for any reason to avoid the native forwarding 186 of certain kinds of packets. 188 This framework focuses on two such scenarios. 190 1. In this scenario, the backbone's interior nodes support only 191 IPv6. They do not maintain IPv4 routes at all, and are not 192 expected to parse IPv4 packet headers. Yet it is desired to 193 use such a backbone to provide transit services for IPv4 194 packets. Therefore tunneled forwarding of IPv4 packets is 195 required. Of course, the edge nodes must have the IPv4 routes, 196 but the ingress must perform an encapsulation in order to get 197 an IPv4 packet forwarded to the egress. 199 2. This scenario is the reverse of scenario 1, i.e., the 200 backbone's interior nodes support only IPv4, but it is desired 201 to use the backbone for IPv6 transit. 203 In these scenarios, a backbone whose interior nodes support only one 204 of the two address families is required to provide transit services 205 for the other. The backbone's edge routers must, of course, support 206 both address families. We use the term "Address Family Border 207 Router" (AFBR) to refer to these PE routers. The tunnels that are 208 used for forwarding are referred to as "softwires". 210 These two scenarios are known as the "Softwire Mesh Problem" [SW- 211 PROB], and the framework specified in this draft is therefore known 212 as the "Softwire Mesh Framework". In this framework, only the AFBRs 213 need to support both address families. The CE routers support only a 214 single address family, and the P routers support only the other 215 address family. 217 It is possible to address these scenarios via a large variety of 218 tunneling technologies. This framework does not mandate the use of 219 any particular tunneling technology. In any given deployment, the 220 choice of tunneling technology is a matter of policy. The framework 221 accommodates at least the use of MPLS ([RFC3031], [RFC3032]), both 222 LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based 223 ([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. 224 The framework will also accommodate the use of IPsec tunneling, when 225 that is necessary in order to meet security requirements. 227 It is expected that in many deployments, the choice of tunneling 228 technology will be made by a simple expression of policy, such as 229 "always use IP-IP tunnels", or "always use LDP-based MPLS", or 230 "always use L2TPv3". 232 However, other deployments may have a mixture of routers, some of 233 which support, say, both GRE and L2TPv3, but others of which support 234 only one of those techniques. It is desirable therefore to allow the 235 network administration to create a small set of classes, and to 236 configure each AFBR to be a member of one or more of these classes. 237 Then the routers can advertise their class memberships to each other, 238 and the encapsulation policies can be expressed as, e.g., "use L2TPv3 239 to tunnel to routers in class X, use GRE to tunnel to routers in 240 class Y". To support such policies, it is necessary for the AFBRs to 241 be able to advertise their class memberships; a standard way of doing 242 this must be developed. 244 Policy may also require a certain class of traffic to receive a 245 certain quality of service, and this may impact the choice of tunnel 246 and/or tunneling technology used for packets in that class. This 247 needs to be accommodated by the softwires framework. 249 The use of tunneled forwarding often requires that some sort of 250 signaling protocol be used to set up and/or maintain the tunnels. 251 Many of the tunneling technologies accommodated by this framework 252 already have their own signaling protocols. However, some do not, 253 and in some cases the standard signaling protocol for a particular 254 tunneling technology may not be appropriate, for one or another 255 reason, in the scenarios of interest. In such cases (and in such 256 cases only), new signaling methodologies need to be defined and 257 standardized. 259 In this framework, the softwires do not form an overlay topology 260 which is visible to routing; routing adjacencies are not maintained 261 over the softwires, and routing control packets are not sent through 262 the softwires. Routing adjacencies among backbone nodes (including 263 the edge nodes) are maintained via the native technology of the 264 backbone. 266 There is already a standard routing method for distributing external 267 routing information among AFBRs, namely BGP. However, in the 268 scenarios of interest, we may be using IPv6-based BGP sessions to 269 pass IPv4 routing information, and we may be using IPv4-based BGP 270 sessions to pass IPv6 routing information. Furthermore, when IPv4 271 traffic is to be tunneled over an IPv6 backbone, it is necessary to 272 encode the "BGP next hop" for an IPv4 route as an IPv6 address, and 273 vice versa. The method for encoding an IPv4 address as the next hop 274 for an IPv6 route is specified in [V6NLRI-V4NH]; the method for 275 encoding an IPv6 address as the next hop for an IPv4 route is 276 specified in [V4NLRI-V6NH]. 278 3. Scenarios of Interest 280 3.1. IPv6-over-IPv4 Scenario 282 In this scenario, the client networks run IPv6 but the backbone 283 network runs IPv4. This is illustrated in Figure 1. 285 +--------+ +--------+ 286 | IPv6 | | IPv6 | 287 | Client | | Client | 288 | Network| | Network| 289 +--------+ +--------+ 290 | \ / | 291 | \ / | 292 | \ / | 293 | X | 294 | / \ | 295 | / \ | 296 | / \ | 297 +--------+ +--------+ 298 | AFBR | | AFBR | 299 +--| IPv4/6 |---| IPv4/6 |--+ 300 | +--------+ +--------+ | 301 +--------+ | | +--------+ 302 | IPv4 | | | | IPv4 | 303 | Client | | | | Client | 304 | Network|------| IPv4 |-------| Network| 305 +--------+ | only | +--------+ 306 | | 307 | +--------+ +--------+ | 308 +--| AFBR |---| AFBR |--+ 309 | IPv4/6 | | IPv4/6 | 310 +--------+ +--------+ 311 | \ / | 312 | \ / | 313 | \ / | 314 | X | 315 | / \ | 316 | / \ | 317 | / \ | 318 +--------+ +--------+ 319 | IPv6 | | IPv6 | 320 | Client | | Client | 321 | Network| | Network| 322 +--------+ +--------+ 324 Figure 1 IPv6-over-IPv4 Scenario 326 The IPv4 transit core may or may not run MPLS. If it does, MPLS may be 327 used as part of the solution. 329 While Figure 1 does not show any "backdoor" connections among the client 330 networks, this framework assumes that there will be such connections. 332 That is, there is no assumption that the only path between two client 333 networks is via the pictured transit core network. Hence the routing 334 solution must be robust in any kind of topology. 336 Many mechanisms for providing IPv6 connectivity across IPv4 networks 337 have been devised over the past ten years. A number of different 338 tunneling mechanisms have been used, some provisioned manually, others 339 based on special addressing. More recently, L3VPN (Layer 3 Virtual 340 Private Network) techniques from [RFC4364] have been extended to provide 341 IPv6 connectivity, using MPLS in the AFBRs and optionally in the 342 backbone [V6NLRI-V4NH]. The solution described in this framework can be 343 thought of as a superset of [V6NLRI-V4NH], with a more generalized 344 scheme for choosing the tunneling (softwire) technology. In this 345 framework, MPLS is allowed, but not required, even at the AFBRs. As in 346 [V6NLRI-V4NH], there is no manual provisioning of tunnels, and no 347 special addressing is required. 349 3.2. IPv4-over-IPv6 Scenario 351 In this scenario, the client networks run IPv4 but the backbone 352 network runs IPv6. This is illustrated in Figure 2. 354 +--------+ +--------+ 355 | IPv4 | | IPv4 | 356 | Client | | Client | 357 | Network| | Network| 358 +--------+ +--------+ 359 | \ / | 360 | \ / | 361 | \ / | 362 | X | 363 | / \ | 364 | / \ | 365 | / \ | 366 +--------+ +--------+ 367 | AFBR | | AFBR | 368 +--| IPv4/6 |---| IPv4/6 |--+ 369 | +--------+ +--------+ | 370 +--------+ | | +--------+ 371 | IPv6 | | | | IPv6 | 372 | Client | | | | Client | 373 | Network|------| IPv6 |-------| Network| 374 +--------+ | only | +--------+ 375 | | 376 | +--------+ +--------+ | 377 +--| AFBR |---| AFBR |--+ 378 | IPv4/6 | | IPv4/6 | 379 +--------+ +--------+ 380 | \ / | 381 | \ / | 382 | \ / | 383 | X | 384 | / \ | 385 | / \ | 386 | / \ | 387 +--------+ +--------+ 388 | IPv4 | | IPv4 | 389 | Client | | Client | 390 | Network| | Network| 391 +--------+ +--------+ 393 Figure 2 IPv4-over-IPv6 Scenario 395 The IPv6 transit core may or may not run MPLS. If it does, MPLS may be 396 used as part of the solution. 398 While Figure 2 does not show any "backdoor" connections among the client 399 networks, this framework assumes that there will be such connections. 401 That is, there is no assumption the only path between two client 402 networks is via the pictured transit core network. Hence the routing 403 solution must be robust in any kind of topology. 405 While the issue of IPv6-over-IPv4 has received considerable attention in 406 the past, the scenario of IPv4-over-IPv6 has not. Yet it is a 407 significant emerging requirement, as a number of service providers are 408 building IPv6 backbone networks and do not wish to provide native IPv4 409 support in their core routers. These service providers have a large 410 legacy of IPv4 networks and applications that need to operate across 411 their IPv6 backbone. Solutions for this do not exist yet because it had 412 always been assumed that the backbone networks of the foreseeable future 413 would be dual stack. 415 4. General Principles of the Solution 417 This section gives a very brief overview of the procedures. The 418 subsequent sections provide more detail. 420 4.1. 'E-IP' and 'I-IP' 422 In the following we use the term "I-IP" ("Internal IP") to refer to 423 the form of IP (i.e., either IPv4 or IPv6) that is supported by the 424 transit network. We use the term "E-IP" ("External IP") to refer to 425 the form of IP that is supported by the client networks. In the 426 scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and 427 E-IP is IPv6 if and only if I-IP is IPv4. 429 We assume that the P routers support only I-IP. That is, they are 430 expected to have only I-IP routing information, and they are not 431 expected to be able to parse E-IP headers. We similarly assume that 432 the CE routers support only E-IP. 434 The AFBRs handle both I-IP and E-IP. However, only I-IP is used on 435 AFBR's "core facing interfaces", and E-IP is only used on its client- 436 facing interfaces. 438 4.2. Routing 440 The P routers and the AFBRs of the transit network participate in an 441 IGP, for the purposes of distributing I-IP routing information. 443 The AFBRs use IBGP to exchange E-IP routing information with each 444 other. Either there is a full mesh of IBGP connections among the 445 AFBRs, or else some or all of the AFBRs are clients of a BGP Route 446 Reflector. Although these IBGP connections are used to pass E-IP 447 routing information (i.e., the NLRI of the BGP updates is in the E-IP 448 address family), the IBGP connections run over I-IP, and the "BGP 449 next hop" for each E-IP NLRI is in the I-IP address family. 451 4.3. Tunneled Forwarding 453 When an ingress AFBR receives an E-IP packet from a client facing 454 interface, it looks up the packet's destination IP address. In the 455 scenarios of interest, the best match for that address will be a BGP- 456 distributed route whose next hop is the I-IP address of another AFBR, 457 the egress AFBR. 459 The ingress AFBR must forward the packet through a tunnel (i.e, 460 through a "softwire") to the egress AFBR. This is done by 461 encapsulating the packet, using an encapsulation header which the P 462 routers can process, and which will cause the P routers to send the 463 packet to the egress AFBR. The egress AFBR then extracts the 464 payload, i.e., the original E-IP packet, and forwards it further by 465 looking up its IP destination address. 467 Several kinds of tunneling technologies are supported. Some of those 468 technologies require explicit AFBR-to-AFBR signaling before the 469 tunnel can be used, others do not. 471 5. Distribution of Inter-AFBR Routing Information 473 AFBRs peer with routers in the client networks to exchange routing 474 information for the E-IP family. 476 AFBRs use BGP to distribute the E-IP routing information to each 477 other. This can be done by an AFBR-AFBR mesh of IBGP sessions, but 478 more likely is done through a BGP Route Reflector, i.e., where each 479 AFBR has an IBGP session to one or two Route Reflectors, rather than 480 to other AFBRs. 482 The BGP sessions between the AFBRs, or between the AFBRs and the 483 Route Reflector, will run on top of the I-IP address family. That 484 is, if the transit core supports only IPv6, the IBGP sessions used to 485 distribute IPv4 routing information from the client networks will run 486 over IPv6; if the transit core supports only IPv4, the IBGP sessions 487 used to distribute IPv6 routing information from the client networks 488 will run over IPv4. The BGP sessions thus use the native networking 489 layer of the core; BGP messages are NOT tunneled through softwires or 490 through any other mechanism. 492 In BGP, a routing update associates an address prefix (or more 493 generally, "Network Layer Reachability Information", or NLRI) with 494 the address of a "BGP Next Hop" (NH). The NLRI is associated with a 495 particular address family. The NH address is also associated with a 496 particular address family, which may be the same as or different than 497 the address family associated with the NLRI. Generally the NH 498 address belongs to the address family that is used to communicate 499 with the BGP speaker to whom the NH address belongs. 501 Since routing updates which contain information about E-IP address 502 prefixes are carried over BGP sessions that use I-IP transport, and 503 since the BGP messages are not tunneled, a BGP update providing 504 information about an E-IP address prefix will need to specify a next 505 hop address in the I-IP family. 507 Due to a variety of historical circumstances, when the NLRI and the 508 NH in a given BGP update are of different address families, it is not 509 always obvious how the NH should be encoded. There is a different 510 encoding procedure for each pair of address families. 512 In the case where the NLRI is in the IPv6 address family, and the NH 513 is in the IPv4 address family, [V6NLRI-V4NH] explains how to encode 514 the NH. 516 In the case where the NLRI is in the IPv4 address family, and the NH 517 is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode 518 the NH. 520 If a BGP speaker sends an update for an NLRI in the E-IP family, and 521 the update is being sent over a BGP session that is running on top of 522 the I-IP network layer, and the BGP speaker is advertising itself as 523 the NH for that NLRI, then the BGP speaker MUST, unless explicitly 524 overridden by policy, specify the NH address in the I-IP family. The 525 address family of the NH MUST NOT be changed by a Route Reflector. 527 In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow 528 this rule unless one's BGP peers have advertised a particular BGP 529 capability. This leads to the following softwires deployment 530 restriction: if a BGP Capability is defined for the case in which an 531 E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST 532 advertise that capability. 534 If an AFBR has multiple IP addresses, the network administrators 535 usually have considerable flexibility in choosing which one the AFBR 536 uses to identify itself as the next hop in a BGP update. However, if 537 the AFBR expects to receive packets through a softwire of a 538 particular tunneling technology, and if the AFBR is known to that 539 tunneling technology via a specific IP address, then that same IP 540 address must be used to identify the AFBR in the next hop field of 541 the BGP updates. For example, if L2TPv3 tunneling is used, then the 542 IP address which the AFBR uses when engaging in L2TPv3 signaling must 543 be the same as the IP address it uses to identify itself in the next 544 hop field of a BGP update. 546 In [V6NLRI-V4NH], IPv6 routing information is distributed using the 547 labeled IPv6 address family. This allows the egress AFBR to 548 associate an MPLS label with each IPv6 address prefix. If an ingress 549 AFBR forwards packets through a softwire than can carry MPLS packets, 550 each data packet can carry the MPLS label corresponding to the IPv6 551 route that it matched. This may be useful at the egress AFBR, for 552 demultiplexing and/or enhanced performance. It is also possible to 553 do the same for the IPv4 address family, i.e. to use the labeled IPv4 554 address family instead of the IPv4 address family. The use of the 555 labeled IP address families in this manner is OPTIONAL. 557 6. Softwire Signaling 559 A mesh of inter-AFBR softwires spanning the transit core must be in 560 place before packets can flow between client networks. Given N dual- 561 stack AFBRs, this requires N^2 "point-to-point IP" or "label switched 562 path" (LSP) tunnels. While in theory these could be configured 563 manually, that would result in a very undesirable O(N^2) provisioning 564 problem. Therefore manual configuration of point-to-point tunnels is 565 not considered part of this framework. 567 Because the transit core is providing layer 3 transit services, 568 point-to-point tunnels are not required by this framework; 569 multipoint-to-point tunnels are all that is needed. In a multipoint- 570 to-point tunnel, when a packet emerges from the tunnel there is no 571 way to tell which router put the packet into the tunnel. This models 572 the native IP forwarding paradigm, wherein the egress router cannot 573 determine a given packet's ingress router. Of course, point-to-point 574 tunnels might be required for some reason which goes beyond the basic 575 requirements described in this document. E.g., QoS or security 576 considerations might require the use of point-to-point tunnels. So 577 point-to-point tunnels are allowed, but not required, by this 578 framework. 580 If it is desired to use a particular tunneling technology for the 581 softwires, and if that technology has its own "native" signaling 582 methodology, the presumption is that the native signaling will be 583 used. This would certainly apply to MPLS-based softwires, where LDP 584 or RSVP-TE would be used. A softwire based on IPsec would use 585 standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] 586 signaling, as that is necessary in order to guarantee the softwire's 587 security properties. 589 A Softwire based on GRE might or might not require signaling, 590 depending on whether various optional GRE header fields are to be 591 used. GRE does not have any "native" signaling, so for those cases, 592 a signaling procedure needs to be developed to support Softwires. 594 Another possible softwire technology is L2TPv3. While L2TPv3 does 595 have its own native signaling, that signaling sets up point-to-point 596 tunnels. For the purpose of softwires, it is better to use L2TPv3 in 597 a multipoint-to-point mode, and this requires a different kind of 598 signaling. 600 The signaling to be used for GRE and L2TPv3 to cover these scenarios 601 is BGP-based, and is described in [ENCAPS-SAFI]. 603 If IP-IP tunneling is used, or if GRE tunneling is used without 604 options, no signaling is required, as the only information needed by 605 the ingress AFBR to create the encapsulation header is the IP address 606 of the egress AFBR, and that is distributed by BGP. 608 When the encapsulation IP header is constructed, there may be fields 609 in the IP whose value is determined neither by whatever signaling has 610 been done nor by the distributed routing information. The values of 611 these fields are determined by policy in the ingress AFBR. Examples 612 of such fields may be the TTL (Time to Live) field, the DSCP 613 (DiffServ Service Classes) bits, etc. 615 It is desirable for all necessary softwires to be fully set up before 616 the arrival of any packets which need to go through the softwires. 617 That is, the softwires should be "always on". From the perspective 618 of any particular AFBR, the softwire endpoints are always BGP next 619 hops of routes which the AFBR has installed. This suggests that any 620 necessary softwire signaling should be either be done as part of 621 normal system startup (as would happen, e.g., with LDP-based MPLS), 622 or else should be triggered by the reception of BGP routing 623 information (such as is described in [ENCAPS-SAFI]); it is also 624 helpful if distribution of the routing information that serves as the 625 trigger is prioritized. 627 7. Choosing to Forward Through a Softwire 629 The decision to forward through a softwire, instead of to forward 630 natively, is made by the ingress AFBR. This decision is a matter of 631 policy. 633 In many cases, the policy will be very simple. Some useful policies 634 are: 636 - if routing says that an E-IP packet has to be sent out a "core- 637 facing interface" to an I-IP core, send the packet through a 638 softwire 640 - if routing says that an E-IP packet has to be sent out an 641 interface that only supports I-IP packets, then send the E-IP 642 packets through a softwire 644 - if routing says that the BGP next hop address for an E-IP packet 645 is an I-IP address, then send the E-IP packets through a softwire 647 - if the route which is the best match for a particular packet's 648 destination address is a BGP-distributed route, then send the 649 packet through a softwire (i.e., tunnel all BGP-routed packets). 651 More complicated policies are also possible, but a consideration of 652 those policies is outside the scope of this document. 654 8. Selecting a Tunneling Technology 656 The choice of tunneling technology is a matter of policy configured 657 at the ingress AFBR. 659 It is envisioned that in most cases, the policy will be a very simple 660 one, and will be the same at all the AFBRs of a given transit core. 661 E.g., "always use LDP-based MPLS", or "always use L2TPv3". 663 However, other deployments may have a mixture of routers, some of 664 which support, say, both GRE and L2TPv3, but others of which support 665 only one of those techniques. It is desirable therefore to allow the 666 network administration to create a small set of classes, and to 667 configure each AFBR to be a member of one or more of these classes. 668 Then the routers can advertise their class memberships to each other, 669 and the encapsulation policies can be expressed as, e.g., "use L2TPv3 670 to talk to routers in class X, use GRE to talk to routers in class 671 Y". To support such policies, it is necessary for the AFBRs to be 672 able to advertise their class memberships. [ENCAPS-SAFI] specifies a 673 way in which an AFBR may advertise, to other AFBRS, various 674 characteristics which may be relevant to the policy (e.g., "I belong 675 to class Y"). In many cases, these characteristics can be 676 represented by arbitrarily selected communities or extended 677 communities, and the policies at the ingress can be expressed in 678 terms of these classes (i.e., communities). 680 Policy may also require a certain class of traffic to receive a 681 certain quality of service, and this may impact the choice of tunnel 682 and/or tunneling technology used for packets in that class. This 683 framework allows a variety of tunneling technologies to be used for 684 instantiating softwires. The choice of tunneling technology is a 685 matter of policy, as discussed in section 2. 687 While in many cases the policy will be unconditional, e.g., "always 688 use L2TPv3 for softwires", in other cases the policy may specify that 689 the choice is conditional upon information about the softwire remote 690 endpoint, e.g., "use L2TPv3 to talk to routers in class X, use GRE to 691 talk to routers in class Y". It is desirable therefore to allow the 692 network administration to create a small set of classes, and to 693 configure each AFBR to be a member of one or more of these classes. 694 If each such class is represented as a community or extended 695 community, then [ENCAPS-SAFI] specifies a method that AFBRs can use 696 to advertise their class memberships to each other. 698 This framework also allows for policies of arbitrary complexity, 699 which may depend on characteristics or attributes of individual 700 address prefixes, as well as on QoS or security considerations. 701 However, the specification of such policies is not within the scope 702 of this document. 704 9. Selecting the Softwire for a Given Packet 706 Suppose it has been decided to send a given packet through a 707 softwire. Routing provides the address, in the address family of the 708 transport network, of the BGP next hop. The packet MUST be sent 709 through a softwire whose remote endpoint address is the same as the 710 BGP next hop address. 712 Sending a packet through a softwire is a matter of encapsulating the 713 packet with an encapsulation header that can be processed by the 714 transit network, and then transmitting towards the softwire's remote 715 endpoint address. 717 In many cases, once one knows the remote endpoint address, one has 718 all the information one needs in order to form the encapsulation 719 header. This will be the case if the tunnel technology instantiating 720 the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without 721 optional header fields. 723 If the tunnel technology being used is L2TPv3 or GRE with optional 724 header fields, additional information from the remote endpoint is 725 needed in order to form the encapsulation header. The procedures for 726 sending and receiving this information are described in [ENCAPS- 727 SAFI]. 729 If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, 730 the native signaling procedures of those technologies will need to be 731 used. 733 If the packet being sent through the softwire matches a route in the 734 labeled IPv4 or labeled IPv6 address families, it should be sent 735 through the softwire as an MPLS packet with the corresponding label. 736 Note that most of the tunneling technologies mentioned in this 737 document are capable of carrying MPLS packets, so this does not 738 presuppose support for MPLS in the core routers. 740 10. Softwire OAM and MIBs 742 10.1. Operations and Maintenance (OAM) 744 Softwires are essentially tunnels connecting routers. If they 745 disappear or degrade in performance then connectivity through those 746 tunnels will be impacted. There are several techniques available to 747 monitor the status of the tunnel end-points (AFBRs) as well as the 748 tunnels themselves. These techniques allow operations such as 749 softwires path tracing, remote softwire end-point pinging and remote 750 softwire end-point liveness failure detection. 752 Examples of techniques applicable to softwire OAM include: 754 o BGP/TCP timeouts between AFBRs 756 o ICMP or LSP echo request and reply addressed to a particular AFBR 758 o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange 759 between AFBR routers 761 Another possibility for softwire OAM is to build something similar to 762 the [RFC4378] or in other words creating and generating softwire echo 763 request/reply packets. The echo request sent to a well-known UDP 764 port would contain the egress AFBR IP address and the softwire 765 identifier as the payload (similar to the MPLS forwarding equivalence 766 class contained in the LSP echo request). The softwire echo packet 767 would be encapsulated with the encapsulation header and forwarded 768 across the same path (inband) as that of the softwire itself. 770 This mechanism can also be automated to periodically verify remote 771 softwires end-point reachability, with the loss of reachability being 772 signaled to the softwires application on the local AFBR thus enabling 773 suitable actions to be taken. Consideration must be given to the 774 trade offs between scalability of such mechanisms verses time to 775 detection of loss of endpoint reachability for such automated 776 mechanisms. 778 In general a framework for softwire OAM can for a large part be based 779 on the [RFC4176] framework. 781 10.2. MIBs 783 Specific MIBs do exist to manage elements of the softwire mesh 784 framework. However there will be a need to either extend these MIBs 785 or create new ones that reflect the functional elements that can be 786 SNMP-managed within the softwire network. 788 11. Softwire Multicast 790 A set of client networks, running E-IP, that are connected to a 791 provider's I-IP transit core, may wish to run IP multicast 792 applications. Extending IP multicast connectivity across the transit 793 core can be done in a number of ways, each with a different set of 794 characteristics. Most (though not all) of the possibilities are 795 either slight variations of the procedures defined for L3VPNs in 796 [L3VPN-MCAST]. 798 We will focus on supporting those multicast features and protocols 799 which are typically used across inter-provider boundaries. Support 800 is provided for PIM-SM (PIM Sparse Mode) and PIM-SSM (PIM Single 801 Source Mode). Support for BIDIR-PIM (Bidirectional PIM), BSR 802 (Bootstrap Router Mechanism for PIM), AutoRP (Automatic Rendezvous 803 Point Determination) is not provided as these features are not 804 typically used across inter-provider boundaries. 806 11.1. One-to-One Mappings 808 In the "one-to-one mapping" scheme, each client multicast tree is 809 extended through the transit core, so that for each client tree there 810 is exactly one tree through the core. 812 The one-to-one scheme is not used in [L3VPN-MCAST], because it 813 requires an amount of state in the core routers which is proportional 814 to the number of client multicast trees passing through the core. In 815 the VPN context, this is considered undesirable, because the amount 816 of state is unbounded and out of the control of the service provider. 817 However, the one-to-one scheme models the typical "Internet 818 multicast" scenario where the client network and the transit core are 819 both IPv4 or are both IPv6. If it scales satisfactorily for that 820 case, it should also scale satisfactorily for the case where the 821 client network and the transit core support different versions of IP. 823 11.1.1. Using PIM in the Core 825 When an AFBR receives an E-IP PIM control message from one of its 826 CEs, it would translate it from E-IP to I-IP, and forward it towards 827 the source of the tree. Since the routers in the transit core will 828 not generally have a route to the source of the tree, the AFBR must 829 create include an "RPF (Reverse Path Forwarding) Vector" [RPF-VECTOR] 830 in the PIM message. 832 Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE, 833 for either an (S,G) tree or a (*,G) tree. The AFBR would have to 834 "translate" the PIM message into an I-IP PIM message. It would then 835 send it to the neighbor which is the next hop along the route to the 836 root of the (S,G) or (*,G) tree. In the case of an (S,G) tree the 837 root of the tree is S; in the case of a (*,G) tree the root of the 838 tree is the Rendezvous Point (RP) for the group G. 840 Note that the address of the root of the tree will be an E-IP 841 address. Since the routers within the transit core (other than the 842 AFBRs) do not have routes to E-IP addresses, A must put an "RPF 843 Vector" [RPF-VECTOR] in the PIM Join/Prune message that it sends to 844 its upstream neighbor. The RPF Vector will identify, as an I-IP 845 address, the AFBR B that is the egress point in the transit network 846 along the route to the root of the multicast tree. AFBR B is AFBR 847 A's "BGP next hop" for the route to the root of the tree. The RPF 848 Vector allows the core routers to forward PIM Join/Prune messages 849 upstream towards the root of the tree, even though they do not 850 maintain E-IP routes. 852 In order to "translate" the an E-IP PIM message into an I-IP PIM 853 message, the AFBR A must translate the address of S (in the case of 854 an (S,G) group) or the address of G's RP from the E-IP address family 855 to the I-IP address family, and the AFBR B must translate them back. 857 In the case where E-IP is IPv4 and I-IP is IPv6, it is possible to do 858 this translation algorithmically. A can translate the IPv4 S and G 859 into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then 860 B can translate them back. The precise circumstances under which 861 these translations are done would be a matter of policy. 863 Obviously, this translation procedure does not generalize to the case 864 where the client multicast is IPv6 but the core is IPv4. To handle 865 that case, one needs additional signaling between the two AFBRs. 866 Each downstream AFBR need to signal the upstream AFBR that it needs a 867 multicast tunnel for (S,G). The upstream AFBR must then assign a 868 multicast address G' to the tunnel, and inform the downstream of the 869 P-G value to use. The downstream AFBR then uses PIM/IPv4 to join the 870 (S', G') tree, where S' is the IPv4 address of the upstream ASBR 871 (Autonomous System Border Router). 873 The (S', G') trees should be SSM trees. 875 This procedure can be used to support client multicasts of either 876 IPv4 or IPv6 over a transit core of the opposite protocol. However, 877 it only works when the client multicasts are SSM, since it provides 878 no method for mapping a client "prune a source off the (*,G) tree" 879 operation into an operation on the (S',G') tree. This method also 880 requires additional signaling. The BGP-based signaling of [L3VPN- 881 MCAST-BGP] is one signaling method that could be used. Other 882 signaling methods could be defined as well. 884 11.1.2. Using mLDP and Multicast MPLS in the Core 886 If the transit core implements mLDP (LDP Extensions for Point-to- 887 Multipoint and Multipoint-to-Multipoint LSPs, [mLDP]) and supports 888 multicast MPLS, then client Single-Source Multicast (SSM) trees can 889 be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs. 891 When an AFBR A receives a E-IP PIM Join/Prune message for (S,G) from 892 one of its CEs, where G is an SSM group it would use mLDP to join a 893 P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's 894 BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely 895 identified by a combination of its root and a "FEC (Forwarding 896 Equivalence Class) identifier". The original (S,G) can be 897 algorithmically encoded into the FEC identifier, so that all AFBRs 898 that need to join the P2MP LSP for (S,G) will generate the same FEC 899 identifier. When the root of the P2MP LSP (AFBR B) receives such an 900 mLDP message, it extracts the original (S,G) from the FEC identifier, 901 creates an "ordinary" E-IP PIM Join/Prune message, and sends it to 902 the CE which is its next hop on the route to S. 904 The method of encoding the (S,G) into the FEC identifier needs to be 905 standardized. The encoding must be self-identifying, so that a node 906 which is the root of a P2MP LSP can determine whether a FEC 907 identifier is the result of having encoded a PIM (S,G). 909 The appropriate state machinery must be standardized so that PIM 910 events at the AFBRs result in the proper mLDP events. For example, 911 if at some point an AFBR determines (via PIM procedures) that it no 912 longer has any downstream receivers for (S,G), the AFBR should invoke 913 the proper mLDP procedures to prune itself off the corresponding P2MP 914 LSP. 916 Note that this method cannot be used when the G is a Sparse Mode 917 group. The reason this method cannot be used is that mLDP does not 918 have any function corresponding to the PIM "prune this source off the 919 shared tree" function. So if a P2MP LSP were mapped one-to-one with 920 a P2MP LSP, duplicate traffic could end up traversing the transit 921 core (i.e., traffic from S might travel down both the shared tree and 922 S's source tree). Alternatively, one could devise an AFBR-to-AFBR 923 protocol to prune sources off the P2MP LSP at the root of the LSP. 924 It is recommended though that client SM multicast groups be supported 925 by other methods, such as those discussed below. 927 Client-side bidirectional multicast groups set up by PIM-bidir could 928 be mapped using the above technique to MP2MP (Multipoint-to- 929 Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this 930 further as inter-provider bidirectional groups are not in use 931 anywhere. 933 11.2. MVPN-like Schemes 935 The "MVPN-like schemes" are those described in [L3VPN-MCAST] and its 936 companion documents (such as [L3VPN-MCAST-BGP]). To apply those 937 schemes to the softwire environment, it is necessary only to treat 938 all the AFBRs of a given transit core as if they were all, for 939 multicast purposes, PE routers attached to the same VPN. 941 The MVPN-like schemes do not require a one-to-one mapping between 942 client multicast trees and transit core multicast trees. In the MVPN 943 environment, it is a requirement that the number of trees in the core 944 scales less than linearly with the number of client trees. This 945 requirement may not hold in the softwires scenarios. 947 The MVPN-like schemes can support SM, SSM, and Bidir groups. They 948 provide a number of options for the control plane: 950 - Lan-Like 952 Use a set of multicast trees in the core to emulate a LAN (Local 953 Area Network), and run the client-side PIM protocol over that 954 "LAN". The "LAN" can consists of a single Bidir tree containing 955 all the AFBRs, or a set of SSM trees, one rooted at each AFBR, 956 and containing all the other AFBRs as receivers. 958 - NBMA (Non-Broadcast Multiple Access), using BGP 960 The client-side PIM signaling can be "translated" into BGP-based 961 signaling, with a BGP route reflector mediating the signaling. 963 These two basic options admit of many variations; a comprehensive 964 discussion is in [L3VPN-MCAST]. 966 For the data plane, there are also a number of options: 968 - All multicast data sent over the emulated LAN. This particular 969 option is not very attractive though for the softwires scenarios, 970 as every AFBR would have to receive every client multicast 971 packet. 973 - Every multicast group mapped to a tree which is considered 974 appropriate for that group, in the sense of causing the traffic 975 of that group to go to "too many" AFBRs that don't need to 976 receive it. 978 Again, a comprehensive discussion of the issues can be found in 979 [L3VPN-MCAST]. 981 12. Inter-AS Considerations 983 We have so far only considered the case where a "transit core" 984 consists of a single Autonomous System (AS). If the transit core 985 consists of multiple ASes, then it may be necessary to use softwires 986 whose endpoints are AFBRs attached to different Autonomous Systems. 987 In this case, the AFBR at the remote endpoint of a softwire is not 988 the BGP next hop for packets that need to be sent on the softwire. 989 Since the procedures described above require the address of remote 990 softwire endpoint to be the same as the address of the BGP next hop, 991 those procedures do not work as specified when the transit core 992 consists of multiple ASes. 994 There are several ways to deal with this situation. 996 1. Don't do it; require that there be AFBRs at the edge of each 997 AS, so that a transit core does not extend more than one AS. 999 2. Use multi-hop EBGP to allow AFBRs to send BGP routes to each 1000 other, even if the ABFRs are not in the same or in neighboring 1001 ASes. 1003 3. Ensure that an ASBR which is not an AFBR does not change the 1004 next hop field of the routes for which encapsulation is needed. 1006 In the latter two cases, BGP recursive next hop resolution needs to 1007 be done, and encapsulations may need to be stacked. 1009 For instance, consider packet P with destination IP address D. 1010 Suppose it arrives at ingress AFBR A1, and that the route that is the 1011 best match for D has BGP next hop B1. So A1 will encapsulate the 1012 packet for delivery to B1. If B1 is not within A1's AS, A1 will need 1013 to look up the route to B1 and then find the BGP next hop, call it 1014 B2, of that route. If the interior routers of A1's AS do not have 1015 routes to B1, then A1 needs to encapsulate the packet a second time, 1016 this time for delivery to B2. 1018 13. IANA Considerations 1020 This document has no actions for IANA. 1022 14. Security Considerations 1024 14.1. Problem Analysis 1026 In the Softwires mesh framework, the data packets that are 1027 encapsulated are E-IP data packets that are traveling through the 1028 Internet. These data packets (the Softwires "payload") may or may 1029 not need such security features as authentication, integrity, 1030 confidentiality, or playback protection. However, the security needs 1031 of the payload packets are independent of whether or not those 1032 packets are traversing softwires. The fact that a particular payload 1033 packet is traveling through a softwire does not in any way affect its 1034 security needs. 1036 Thus the only security issues we need to consider are those which 1037 affect the I-IP encapsulation headers, rather than those which affect 1038 the E-IP payload. 1040 Since the encapsulation headers determine the routing of packets 1041 traveling through softwires, they must appear "in the clear", i.e., 1042 they do not have any confidentiality requirement. 1044 In the Softwires mesh framework, for each tunnel receiving endpoint, 1045 there are one or more "valid" transmitting endpoints, where the valid 1046 transmitting endpoints are those which are authorized to tunnel 1047 packets to the receiving endpoint. If the encapsulation header has 1048 no guarantee of authentication or integrity, then it is possible to 1049 have spoofing attacks, in which unauthorized nodes send encapsulated 1050 packets to the receiving endpoint, giving the receiving endpoint the 1051 invalid impression the encapsulated packets have really traveled 1052 through the softwire. Replay attacks are also possible. 1054 The effect of such attacks is somewhat limited though. The receiving 1055 endpoint of a softwire decapsulates the payload and does further 1056 routing based on the IP destination address of the payload. Since 1057 the payload packets are traveling through the Internet, they have 1058 addresses from the globally unique address space (rather than, e.g., 1059 from a private address space of some sort). Therefore these attacks 1060 cannot cause payload packets to be delivered to an address other than 1061 the one intended. 1063 However, attacks of this sort can result in policy violations. The 1064 authorized transmitting endpoint(s) of a softwire may be following a 1065 policy according to which only certain payload packets get sent 1066 through the softwire. If unauthorized nodes are able to encapsulate 1067 the payload packets so that they arrive at the receiving endpoint 1068 looking as if they arrived from authorized nodes, then the properly 1069 authorized policies have been side-stepped. 1071 Attacks of the sort we are considering can also be used in Denial of 1072 Service attacks on the receiving tunnel endpoints. However, such 1073 attacks cannot be prevented by use of cryptographic 1074 authentication/integrity techniques, as the need to do cryptography 1075 on spoofed packets only makes the Denial of Service problem worse. 1077 This section is largely based on the security considerations section 1078 of RFC 4023, which also deals with encapsulations and tunnels. 1080 14.2. Non-cryptographic techniques 1082 If a tunnel lies entirely within a single administrative domain, then 1083 to a certain extent, then there are certain non-cryptographic 1084 techniques one can use to prevent spoofed packets from reaching a 1085 tunnel's receiving endpoint. For example, when the tunnel 1086 encapsulation is IP-based: 1088 - The tunnel receiving endpoints can be given a distinct set of 1089 addresses, and those addresses can be made known to the border 1090 routers. The border routers can then filter out packets, 1091 destined to those addresses, which arrive from outside the 1092 domain. 1094 - The tunnel transmitting endpoints can be given a distinct set of 1095 addresses, and those addresses can be made known to the border 1096 routers and to the tunnel receiving endpoints. The border routers 1097 can filter out all packets arriving from outside the domain with 1098 source addresses that are in this set, and the receiving 1099 endpoints can discard all packets which appear to be part of a 1100 softwire, but whose source addresses are not in this set. 1102 If an MPLS-based encapsulation is used, the border routers can refuse 1103 to accept MPLS packets from outside the domain, or can refuse to 1104 accept such MPLS packets whenever the top label corresponds to the 1105 address of a tunnel receiving endpoint. 1107 These techniques assume that within a domain, the network is secure 1108 enough to prevent the introduction of spoofed packets from within the 1109 domain itself. That may not always be the case. Also, these 1110 techniques however can be difficult or impossible to use effectively 1111 for tunnels that are not in the same administrative domain. 1113 A different technique is to have the encapsulation header contain a 1114 cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is 1115 sometimes used in this way. This can be useful within an 1116 administrative domain if it is regarded as infeasible for an attacker 1117 to spy on packets that originate in the domain and that do not leave 1118 the domain. An attacker would then not be able to discover the 1119 password. An attacker could of course try to guess the password, but 1120 if the password is an arbitrary 64-bit binary sequence, brute force 1121 attacks which run through all the possible passwords would be 1122 infeasible. This technique may be easier to manage than ingress 1123 filtering is, and may be just as effective if the assumptions hold. 1124 Like ingress filtering, though, it may not be applicable for tunnels 1125 that cross domain boundaries. 1127 Therefore it is necessary to also consider the use of cryptographic 1128 techniques for setting up the tunnels and for passing data through 1129 them. 1131 14.3. Cryptographic techniques 1133 If the path between the two endpoints of a tunnel is not adequately 1134 secure, then 1136 - If a control protocol is used to set up the tunnels (e.g., to 1137 inform one tunnel endpoint of the IP address of the other), the 1138 control protocol MUST have an authentication mechanism, and this 1139 MUST be used when the tunnel is set up. If the tunnel is set up 1140 automatically as the result of, for example, information 1141 distributed by BGP, then the use of BGP's MD5-based 1142 authentication mechanism [RFC2385] is satisfactory. 1144 - Data transmission through the tunnel should be secured with 1145 IPsec. In the remainder of this section, we specify the way 1146 IPsec may be used, and the implementation requirements we mention 1147 are meant to be applicable whenever IPsec is being used. 1149 We consider only the case where IPsec is used together with an IP- 1150 based tunneling mechanism. Use of IPsec with an MPLS-based tunneling 1151 mechanism is for further study. 1153 If it is deemed necessary to use tunnels that are protected by IPsec, 1154 the tunnel type SHOULD be negotiated by the tunnel endpoints using 1155 the procedures specified in [ENCAPS-IPSEC]. That document allows the 1156 use of IPsec tunnel mode, but also allows one to treat the tunnel 1157 head and the tunnel tail as the endpoints of a Security Association, 1158 and to use IPsec transport mode. 1160 In order to use IPsec transport mode, encapsulated packets should be 1161 viewed as originating at the tunnel head and as being destined for 1162 the tunnel tail. A single IP address of the tunnel head will be used 1163 as the source IP address, and a single IP address of the tunnel tail 1164 will be used as the destination IP address. This technique can be 1165 used to to carry MPLS packets through an IPsec Security Association, 1166 but first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE 1167 [RFC4023] and then applying IPsec transport mode. 1169 When IPsec is used to secure softwires, IPsec MUST provide 1170 authentication and integrity. Thus, the implementation MUST support 1171 either ESP (IP Encapsulating Security Payload) with null encryption 1172 [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with 1173 encryption MAY be supported. If ESP is used, the tunnel tail MUST 1174 check that the source IP address of any packet received on a given SA 1175 (IPsec Security Association) is the one expected, as specified in 1176 [RFC4301] section 5.2 step 4. 1178 Since the softwires are set up dynamically as a byproduct of passing 1179 routing information, key distribution MUST be done automatically by 1180 means of IKEv2 [RFC4306], operating in main mode with preshared keys. 1181 If a PKI (Public Key Infrastructure) is not available, the IPsec 1182 Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used 1183 and validated before setting up an SA. 1185 The selectors associated with the SA are the source and destination 1186 addresses of the encapsulation header, along with the IP protocol 1187 number representing the encapsulation protocol being used. 1189 15. Acknowledgments 1191 David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, 1192 Mingwei Xu and Ke Xu provided useful input into this document. 1194 16. Normative References 1196 [ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger, 1197 R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-01.txt, April 1198 2008. 1200 [ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation 1201 Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps- 1202 safi-03.txt, June 2008. 1204 [RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996. 1206 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 1207 S. Bradner, March 1997. 1209 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, 1210 S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000. 1212 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. 1213 Viswanathan, R. Callon, RFC 3031, January 2001. 1215 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. 1216 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, RFC 3032, 1217 January 2001. 1219 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. 1220 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 1221 December 2001. 1223 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 1224 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1226 [RFC4023] "Encapsulating MPLS in IP or Generic Routing Encapsulation 1227 (GRE)", T. Worster, Y. Rekhter, E. Rosen, RFC 4023, March 2005. 1229 [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI 1230 with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-01.txt, April 1231 2008. 1233 [V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, 1234 "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge 1235 Routers (6PE)", RFC 4798, February 2007. 1237 17. Informative References 1239 [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", 1240 draft-ietf-bfd-base-08.txt, March 2008. 1242 [L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. 1243 Aggarwal, draft-ietf-l3vpn-2547bis-mcast-07.txt, July 2008. 1245 [L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in 1246 MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. 1247 Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008. 1249 [MLDP] "Label Distribution Protocol Extensions for Point-to- 1250 Multipoint and Multipoint-to-Multipoint Label Switched Paths", I. 1251 Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp- 1252 p2mp-05.txt, June 2008. 1254 [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual 1255 Environments", R. Callon, RFC 1195, December 1990. 1257 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 1259 [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature 1260 Option", A. Heffernan, RFC 2385, August 1998. 1262 [RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A. 1263 Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) 1264 Operations and Management", RFC 4176, October 2005. 1266 [RFC4271] Rekhter, Y,, Li T., Hares, S., "A Border Gateway Protocol 4 1267 (BGP-4)", RFC 4271, January 2006. 1269 [RFC4291] "IP Version 6 Addressing Architecture", R. Hinden, S. 1270 Deering, RFC 4291, February 2006. 1272 [RFC4301], "Security Architecture for the Internet Protocol", S. 1273 Kent, K. Seo, RFC 4301, December 2005. 1275 [RFC4302] "IP Authentication Header", S. Kent, RFC 4302, December 1276 2005. 1278 [RFC4303] "IP Encapsulating Security Payload (ESP)", S. Kent, RFC 1279 4303, December 2005. 1281 [RFC4306] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, ed., 1282 RFC 4306, December 2005. 1284 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1285 Networks (VPNs)", RFC 4364, February 2006. 1287 [RFC4378] D. Allan and T. Nadeau, "A Framework for Multi-Protocol 1288 Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, 1289 February 2006. 1291 [RFC5036] "LDP Specification", L. Andersson, I. Minei, B. Thomas, 1292 October 2007. 1294 [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, A. Boers, E. Rosen, 1295 draft-ietf-pim-rpf-vector-06.txt, February 2008. 1297 [SW-PROB] X. Li, S. Dawkins, D. Ward, A. Durand, "Softwire Problem 1298 Statement", RFC 4925, July 2007. 1300 Authors' Addresses 1302 Jianping Wu 1303 Tsinghua University 1304 Department of Computer Science, Tsinghua University 1305 Beijing 100084 1306 P.R.China 1308 Phone: +86-10-6278-5983 1309 Email: jianping@cernet.edu.cn 1310 Yong Cui 1311 Tsinghua University 1312 Department of Computer Science, Tsinghua University 1313 Beijing 100084 1314 P.R.China 1316 Phone: +86-10-6278-5822 1317 Email: yong@csnet1.cs.tsinghua.edu.cn 1319 Xing Li 1320 Tsinghua University 1321 Department of Electronic Engineering, Tsinghua University 1322 Beijing 100084 1323 P.R.China 1325 Phone: +86-10-6278-5983 1326 Email: xing@cernet.edu.cn 1328 Chris Metz 1329 Cisco Systems, Inc. 1330 3700 Cisco Way 1331 San Jose, Ca. 95134 1332 USA 1334 Email: chmetz@cisco.com 1336 Eric C. Rosen 1337 Cisco Systems, Inc. 1338 1414 Massachusetts Avenue 1339 Boxborough, MA, 01719 1340 USA 1342 Email: erosen@cisco.com 1343 Simon Barber 1344 Cisco Systems, Inc. 1345 250 Longwater Avenue 1346 Reading, ENGLAND, RG2 6GB 1347 United Kingdom 1349 Email: sbarber@cisco.com 1351 Pradosh Mohapatra 1352 Cisco Systems, Inc. 1353 3700 Cisco Way 1354 San Jose, Ca. 95134 1355 USA 1357 Email: pmohapat@cisco.com 1359 John Scudder 1360 Juniper Networks 1361 1194 North Mathilda Avenue 1362 Sunnyvale, California 94089 1363 USA 1365 Email: jgs@juniper.net 1367 18. Full Copyright Statement 1369 Copyright (C) The IETF Trust (2008). 1371 This document is subject to the rights, licenses and restrictions 1372 contained in BCP 78, and except as set forth therein, the authors 1373 retain all their rights. 1375 This document and the information contained herein are provided on an 1376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1378 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1379 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1383 19. Intellectual Property 1385 The IETF takes no position regarding the validity or scope of any 1386 Intellectual Property Rights or other rights that might be claimed to 1387 pertain to the implementation or use of the technology described in 1388 this document or the extent to which any license under such rights 1389 might or might not be available; nor does it represent that it has 1390 made any independent effort to identify any such rights. Information 1391 on the procedures with respect to rights in RFC documents can be 1392 found in BCP 78 and BCP 79. 1394 Copies of IPR disclosures made to the IETF Secretariat and any 1395 assurances of licenses to be made available, or the result of an 1396 attempt made to obtain a general license or permission for the use of 1397 such proprietary rights by implementers or users of this 1398 specification can be obtained from the IETF on-line IPR repository at 1399 http://www.ietf.org/ipr. 1401 The IETF invites any interested party to bring to its attention any 1402 copyrights, patents or patent applications, or other proprietary 1403 rights that may cover technology that may be required to implement 1404 this standard. Please address the information to the IETF at ietf- 1405 ipr@ietf.org.