idnits 2.17.1 draft-wu-softwire-mesh-framework-02.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 1004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1028. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a BGP speaker sends an update for an NLRI in the E-IP family, and the update is being sent over a BGP session that is running on top of the I-IP network layer, and the BGP speaker is advertising itself as the NH for that NLRI, then the BGP speaker MUST, unless explicitly overridden by policy, specify the NH address in the I-IP family. The address family of the NH MUST not be changed by a Route Reflector. -- 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 (February 2007) is 6280 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 (-02) exists of draft-pmohapat-idr-info-safi-00 -- Possible downref: Normative reference to a draft: ref. 'ENCAPS-SAFI' == Outdated reference: A later version (-01) exists of draft-lefaucheur-idr-v4nlri-v6nh-00 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-04 == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-00 Summary: 2 errors (**), 0 flaws (~~), 7 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 Expiration Date: August 2007 X. Li 5 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 February 2007 18 Softwire Mesh Framework 20 draft-wu-softwire-mesh-framework-02.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 ...................... 3 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 ............................................ 12 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 12 Inter-AS Considerations ............................ 20 86 13 Security Considerations ............................ 21 87 14 Acknowledgments .................................... 21 88 15 Normative References ............................... 21 89 16 Informative References ............................. 22 90 17 Full Copyright Statement ........................... 25 91 18 Intellectual Property .............................. 25 93 1. Specification of requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 The routing information in any IP backbone network can be thought of 102 as being in one of two categories: "internal routing information" or 103 "external routing information". The internal routing information 104 consists of routes to the nodes that belong to the backbone, and to 105 the interfaces of those nodes. External routing information consists 106 of routes to destinations beyond the backbone, especially 107 destinations to which the backbone is not directly attached. In 108 general, BGP [RFC4271] is used to distribute external routing 109 information, and an "Interior Gateway Protocol" (IGP) such as OSPF 110 [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing 111 information. 113 Often an IP backbone will provide transit routing services for 114 packets that originate outside the backbone, and whose destinations 115 are outside the backbone. These packets enter the backbone at one of 116 its "edge routers". They are routed through the backbone to another 117 edge router, after which they leave the backbone and continue on 118 their way. The edge nodes of the backbone are often known as 119 "Provider Edge" (PE) routers. The term "ingress" (or "ingress PE") 120 refers to the router at which a packet enters the backbone, and the 121 term "egress" (or "egress PE") refers to the router at which it 122 leaves the backbone. Interior nodes are often known as "P routers". 123 Routers which are outside the backbone but directly attached to it 124 are known as "Customer Edge" (CE) routers. (This terminology is 125 taken from [RFC4364].) 127 When a packet's destination is outside the backbone, the routing 128 information which is needed within the backbone in order to route the 129 packet to the proper egress is, by definition, external routing 130 information. 132 Traditionally, the external routing information has been distributed 133 by BGP to all the routers in the backbone, not just to the edge 134 routers (i.e., not just to the ingress and egress points). Each of 135 the interior nodes has been expected to look up the packet's 136 destination address and route it towards the egress point. This is 137 known as "native forwarding": the interior nodes look into each 138 packet's header in order to match the information in the header with 139 the external routing information. 141 It is, however, possible to provide transit services without 142 requiring that all the backbone routers have the external routing 143 information. The routing information which BGP distributes to each 144 ingress router specifies the egress router for each route. The 145 ingress router can therefore "tunnel" the packet directly to the 146 egress router. "Tunneling the packet" means putting on some sort of 147 encapsulation header which will force the interior routers to forward 148 the packet to the egress router. The original packet is known as the 149 "encapsulation payload". The P routers do not look at the packet 150 header of the payload, but only at the encapsulation header. Since 151 the path to the egress router is part of the internal routing 152 information of the backbone, the interior routers then do not need to 153 know the external routing information. This is known as "tunneled 154 forwarding". Of course, before the packet can leave the egress, it 155 has to be decapsulated. 157 The scenario where the P routers do not have external routes is 158 sometimes known as a "BGP-free core". That is something of a 159 misnomer, though, since the crucial aspect of this scenario is not 160 that the interior nodes don't run BGP, but that they don't maintain 161 the external routing information. 163 In recent years, we have seen this scenario deployed to support VPN 164 services, as specified in [RFC4364]. An edge router maintains 165 multiple independent routing/addressing spaces, one for each VPN to 166 which it interfaces. However, the routing information for the VPNs 167 is not maintained by the interior routers. In most of these 168 scenarios, MPLS is used as the encapsulation mechanism for getting 169 the packets from ingress to egress. There are some deployments in 170 which an IP-based encapsulation, such as L2TPv3 [RFC3931] or GRE 171 [RFC2784] is used. 173 This same technique can also be useful when the external routing 174 information consists not of VPN routes, but of "ordinary" Internet 175 routes. It can be used any time it is desired to keep external 176 routing information out of a backbone's interior nodes, or in fact 177 any time it is desired for any reason to avoid the native forwarding 178 of certain kinds of packets. 180 This framework focuses on two such scenarios. 182 1. In this scenario, the backbone's interior nodes support only 183 IPv6. They do not maintain IPv4 routes at all, and are not 184 expected to parse IPv4 packet headers. Yet it is desired to 185 use such a backbone to provide transit services for IPv4 186 packets. Therefore tunneled forwarding of IPv4 packets is 187 required. Of course, the edge nodes must have the IPv4 routes, 188 but the ingress must perform an encapsulation in order to get 189 an IPv4 packet forwarded to the egress. 191 2. This scenario is the reverse of scenario 1, i.e., the 192 backbone's interior nodes support only IPv4, but it is desired 193 to use the backbone for IPv6 transit. 195 In these scenarios, a backbone whose interior nodes support only one 196 of the two address families is required to provide transit services 197 for the other. The backbone's edge routers must, of course, support 198 both address families. We use the term "Address Family Border 199 Router" (AFBR) to refer to these PE routers. The tunnels that are 200 used for forwarding are referred to as "softwires". 202 These two scenarios are known as the "Softwire Mesh Problem" [SW- 203 PROB], and the framework specified in this draft is therefore known 204 as the "Softwire Mesh Framework". In this framework, only the AFBRs 205 need to support both address families. The CE routers support only a 206 single address family, and the P routers support only the other 207 address family. 209 It is possible to address these scenarios via a large variety of 210 tunneling technologies. This framework does not mandate the use of 211 any particular tunneling technology. In any given deployment, the 212 choice of tunneling technology is a matter of policy. The framework 213 accommodates at least the use of MPLS ([RFC3031], [RFC3032]), both 214 LDP-based ([RFC3036]) and RSVP-TE-based ([RFC3209]), L2TPv3 215 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. The framework will 216 also accommodate the use of IPsec tunneling, when that is necessary 217 in order to meet security requirements. 219 It is expected that in many deployments, the choice of tunneling 220 technology will be made by a simple expression of policy, such as 221 "always use IP-IP tunnels", or "always use LDP-based MPLS", or 222 "always use L2TPv3". 224 However, other deployments may have a mixture of routers, some of 225 which support, say, both GRE and L2TPv3, but others of which support 226 only one of those techniques. It is desirable therefore to allow the 227 network administration to create a small set of classes, and to 228 configure each AFBR to be a member of one or more of these classes. 229 Then the routers can advertise their class memberships to each other, 230 and the encapsulation policies can be expressed as, e.g., "use L2TPv3 231 to tunnel to routers in class X, use GRE to tunnel to routers in 232 class Y". To support such policies, it is necessary for the AFBRs to 233 be able to advertise their class memberships; a standard way of doing 234 this must be developed. 236 Policy may also require a certain class of traffic to receive a 237 certain quality of service, and this may impact the choice of tunnel 238 and/or tunneling technology used for packets in that class. This 239 needs to be accommodated by the softwires framework. 241 The use of tunneled forwarding often requires that some sort of 242 signaling protocol be used to set up and/or maintain the tunnels. 244 Many of the tunneling technologies accommodated by this framework 245 already have their own signaling protocols. However, some do not, 246 and in some cases the standard signaling protocol for a particular 247 tunneling technology may not be appropriate, for one or another 248 reason, in the scenarios of interest. In such cases (and in such 249 cases only), new signaling methodologies need to be defined and 250 standardized. 252 In this framework, the softwires do not form an overlay topology 253 which is visible to routing; routing adjacencies are not maintained 254 over the softwires, and routing control packets are not sent through 255 the softwires. Routing adjacencies among backbone nodes (including 256 the edge nodes) are maintained via the native technology of the 257 backbone. 259 There is already a standard routing method for distributing external 260 routing information among AFBRs, namely BGP. However, in the 261 scenarios of interest, we may be using IPv6-based BGP sessions to 262 pass IPv4 routing information, and we may be using IPv4-based BGP 263 sessions to pass IPv6 routing information. Furthermore, when IPv4 264 traffic is to be tunneled over an IPv6 backbone, it is necessary to 265 encode the "BGP next hop" for an IPv4 route as an IPv6 address, and 266 vice versa. The method for encoding an IPv4 address as the next hop 267 for an IPv6 route is specified in [V6NLRI-V4NH]; the method for 268 encoding an IPv6 address as the next hop for an IPv4 route is 269 specified in [V4NLRI-V6NH]. 271 3. Scenarios of Interest 273 3.1. IPv6-over-IPv4 Scenario 275 In this scenario, the client networks run IPv6 but the backbone 276 network runs IPv4. This is illustrated in Figure 1. 278 +--------+ +--------+ 279 | IPv6 | | IPv6 | 280 | Client | | Client | 281 | Network| | Network| 282 +--------+ +--------+ 283 | \ / | 284 | \ / | 285 | \ / | 286 | X | 287 | / \ | 288 | / \ | 289 | / \ | 290 +--------+ +--------+ 291 | AFBR | | AFBR | 292 +--| IPv4/6 |---| IPv4/6 |--+ 293 | +--------+ +--------+ | 294 +--------+ | | +--------+ 295 | IPv4 | | | | IPv4 | 296 | Client | | | | Client | 297 | Network|------| IPv4 |-------| Network| 298 +--------+ | only | +--------+ 299 | | 300 | +--------+ +--------+ | 301 +--| AFBR |---| AFBR |--+ 302 | IPv4/6 | | IPv4/6 | 303 +--------+ +--------+ 304 | \ / | 305 | \ / | 306 | \ / | 307 | X | 308 | / \ | 309 | / \ | 310 | / \ | 311 +--------+ +--------+ 312 | IPv6 | | IPv6 | 313 | Client | | Client | 314 | Network| | Network| 315 +--------+ +--------+ 317 Figure 1 IPv6-over-IPv4 Scenario 319 The IPv4 transit core may or may not run MPLS. If it does, MPLS may 320 be used as part of the solution. 322 While Figure 1 does not show any "backdoor" connections among the 323 client networks, this framework assumes that there will be such 324 connections. That is, there is no assumption that the only path 325 between two client networks is via the pictured transit core network. 326 Hence the routing solution must be robust in any kind of topology. 328 Many mechanisms for providing IPv6 connectivity across IPv4 networks 329 have been devised over the past ten years. A number of different 330 tunneling mechanisms have been used, some provisioned manually, 331 others based on special addressing. More recently, L3VPN techniques 332 from [RFC4364] have been extended to provide IPv6 connectivity, using 333 MPLS in the AFBRs and optionally in the backbone [V6NLRI-V4NH]. The 334 solution described in this framework can be thought of as a superset 335 of [V6NLRI-V4NH], with a more generalized scheme for choosing the 336 tunneling (softwire) technology. In this framework, MPLS is allowed, 337 but not required, even at the AFBRs. As in [V6NLRI-V4NH], there is 338 no manual provisioning of tunnels, and no special addressing is 339 required. 341 3.2. IPv4-over-IPv6 Scenario 343 In this scenario, the client networks run IPv4 but the backbone 344 network runs IPv6. This is illustrated in Figure 2. 346 +--------+ +--------+ 347 | IPv4 | | IPv4 | 348 | Client | | Client | 349 | Network| | Network| 350 +--------+ +--------+ 351 | \ / | 352 | \ / | 353 | \ / | 354 | X | 355 | / \ | 356 | / \ | 357 | / \ | 358 +--------+ +--------+ 359 | AFBR | | AFBR | 360 +--| IPv4/6 |---| IPv4/6 |--+ 361 | +--------+ +--------+ | 362 +--------+ | | +--------+ 363 | IPv6 | | | | IPv6 | 364 | Client | | | | Client | 365 | Network|------| IPv6 |-------| Network| 366 +--------+ | only | +--------+ 367 | | 368 | +--------+ +--------+ | 369 +--| AFBR |---| AFBR |--+ 370 | IPv4/6 | | IPv4/6 | 371 +--------+ +--------+ 372 | \ / | 373 | \ / | 374 | \ / | 375 | X | 376 | / \ | 377 | / \ | 378 | / \ | 379 +--------+ +--------+ 380 | IPv4 | | IPv4 | 381 | Client | | Client | 382 | Network| | Network| 383 +--------+ +--------+ 385 Figure 2 IPv4-over-IPv6 Scenario 387 The IPv6 transit core may or may not run MPLS. If it does, MPLS may 388 be used as part of the solution. 390 While Figure 2 does not show any "backdoor" connections among the 391 client networks, this framework assumes that there will be such 392 connections. That is, there is no assumption the only path between 393 two client networks is via the pictured transit core network. Hence 394 the routing solution must be robust in any kind of topology. 396 While the issue of IPv6-over-IPv4 has received considerable attention 397 in the past, the scenario of IPv4-over-IPv6 has not. Yet it is a 398 significant emerging requirement, as a number of service providers 399 are building IPv6 backbone networks and do not wish to provide native 400 IPv4 support in their core routers. These service providers have a 401 large legacy of IPv4 networks and applications that need to operate 402 across their IPv6 backbone. Solutions for this do not exist yet 403 because it had always been assumed that the backbone networks of the 404 foreseeable future would be dual stack. 406 4. General Principles of the Solution 408 This section gives a very brief overview of the procedures. The 409 subsequent sections provide more detail. 411 4.1. 'E-IP' and 'I-IP' 413 In the following we use the term "I-IP" ("Internal IP") to refer to 414 the form of IP (i.e., either IPv4 or IPv6) that is supported by the 415 transit network. We use the term "E-IP" ("External IP") to refer to 416 the form of IP that is supported by the client networks. In the 417 scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and 418 E-IP is IPv6 if and only if I-IP is IPv4. 420 We assume that the P routers support only I-IP. That is, they are 421 expected to have only I-IP routing information, and they are not 422 expected to be able to parse E-IP headers. We similarly assume that 423 the CE routers support only E-IP. 425 The AFBRs handle both I-IP and E-IP. However, only I-IP is used on 426 AFBR's "core facing interfaces", and E-IP is only used on its 427 client-facing interfaces. 429 4.2. Routing 431 The P routers and the AFBRs of the transit network participate in an 432 IGP, for the purposes of distributing I-IP routing information. 434 The AFBRs use IBGP to exchange E-IP routing information with each 435 other. Either there is a full mesh of IBGP connections among the 436 AFBRs, or else some or all of the AFBRs are clients of a BGP Route 437 Reflector. Although these IBGP connections are used to pass E-IP 438 routing information (i.e., the NLRI of the BGP updates is in the E-IP 439 address family), the IBGP connections run over I-IP, and the "BGP 440 next hop" for each E-IP NLRI is in the I-IP address family. 442 4.3. Tunneled Forwarding 444 When an ingress AFBR receives an E-IP packet from a client facing 445 interface, it looks up the packet's destination IP address. In the 446 scenarios of interest, the best match for that address will be a 447 BGP-distributed route whose next hop is the I-IP address of another 448 AFBR, the egress AFBR. 450 The ingress AFBR must forward the packet through a tunnel (i.e, 451 through a "softwire") to the egress AFBR. This is done by 452 encapsulating the packet, using an encapsulation header which the P 453 routers can process, and which will cause the P routers to send the 454 packet to the egress AFBR. The egress AFBR then extracts the 455 payload, i.e., the original E-IP packet, and forwards it further by 456 looking up its IP destination address. 458 Several kinds of tunneling technologies are supported. Some of those 459 technologies require explicit AFBR-to-AFBR signaling before the 460 tunnel can be used, others do not. 462 5. Distribution of Inter-AFBR Routing Information 464 AFBRs peer with routers in the client networks to exchange routing 465 information for the E-IP family. 467 AFBRs use BGP to distribute the E-IP routing information to each 468 other. This can be done by an AFBR-AFBR mesh of IBGP sessions, but 469 more likely is done through a BGP Route Reflector, i.e., where each 470 AFBR has an IBGP session to one or two Route Reflectors, rather than 471 to other AFBRs. 473 The BGP sessions between the AFBRs, or between the AFBRs and the 474 Route Reflector, will run on top of the I-IP address family. That 475 is, if the transit core supports only IPv6, the IBGP sessions used to 476 distribute IPv4 routing information from the client networks will run 477 over IPv6; if the transit core supports only IPv4, the IBGP sessions 478 used to distribute IPv6 routing information from the client networks 479 will run over IPv4. The BGP sessions thus use the native networking 480 layer of the core; BGP messages are NOT tunneled through softwires or 481 through any other mechanism. 483 In BGP, a routing update associates an address prefix (or more 484 generally, "Network Layer Reachability Information", or NLRI) with 485 the address of a "BGP Next Hop" (NH). The NLRI is associated with a 486 particular address family. The NH address is also associated with a 487 particular address family, which may be the same as or different than 488 the address family associated with the NLRI. Generally the NH 489 address belongs to the address family that is used to communicate 490 with the BGP speaker to whom the NH address belongs. 492 Since routing updates which contain information about E-IP address 493 prefixes are carried over BGP sessions that use I-IP transport, and 494 since the BGP messages are not tunneled, a BGP update providing 495 information about an E-IP address prefix will need to specify a next 496 hop address in the I-IP family. 498 Due to a variety of historical circumstances, when the NLRI and the 499 NH in a given BGP update are of different address families, it is not 500 always obvious how the NH should be encoded. There is a different 501 encoding procedure for each pair of address families. 503 In the case where the NLRI is in the IPv6 address family, and the NH 504 is in the IPv4 address family, [V6NLRI-V4NH] explains how to encode 505 the NH. 507 In the case where the NLRI is in the IPv4 address family, and the NH 508 is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode 509 the NH. 511 If a BGP speaker sends an update for an NLRI in the E-IP family, and 512 the update is being sent over a BGP session that is running on top of 513 the I-IP network layer, and the BGP speaker is advertising itself as 514 the NH for that NLRI, then the BGP speaker MUST, unless explicitly 515 overridden by policy, specify the NH address in the I-IP family. The 516 address family of the NH MUST not be changed by a Route Reflector. 518 In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow 519 this rule unless one's BGP peers have advertised a particular BGP 520 capability. This leads to the following softwires deployment 521 restriction: if a BGP Capability is defined for the case in which an 522 E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST 523 advertise that capability. 525 If an AFBR has multiple IP addresses, the network administrators 526 usually have considerable flexibility in choosing which one the AFBR 527 uses to identify itself as the next hop in a BGP update. However, if 528 the AFBR expects to receive packets through a softwire of a 529 particular tunneling technology, and if the AFBR is known to that 530 tunneling technology via a specific IP address, then that same IP 531 address must be used to identify the AFBR in the next hop field of 532 the BGP updates. For example, if L2TPv3 tunneling is used, then the 533 IP address which the AFBR uses when engaging in L2TPv3 signaling must 534 be the same as the IP address it uses to identify itself in the next 535 hop field of a BGP update. 537 In [V6NLRI-V4NH], IPv6 routing information is distributed using the 538 labeled IPv6 address family. This allows the egress AFBR to 539 associate an MPLS label with each IPv6 address prefix. If an ingress 540 AFBR forwards packets through a softwire than can carry MPLS packets, 541 each data packet can carry the MPLS label corresponding to the IPv6 542 route that it matched. This may be useful at the egress AFBR, for 543 demultiplexing and/or enhanced performance. It is also possible to 544 do the same for the IPv4 address family, i.e. to use the labeled IPv4 545 address family instead of the IPv4 address family. The use of the 546 labeled IP address families in this manner is OPTIONAL. 548 6. Softwire Signaling 550 A mesh of inter-AFBR softwires spanning the transit core must be in 551 place before packets can flow between client networks. Given N 552 dual-stack AFBRs, this requires N^2 "point-to-point IP" or "label 553 switched path" (LSP) tunnels. While in theory these could be 554 configured manually, that would result in a very undesirable O(N^2) 555 provisioning problem. Therefore manual configuration of point-to- 556 point tunnels is not considered part of this framework. 558 Because the transit core is providing layer 3 transit services, 559 point-to-point tunnels are not required by this framework; 560 multipoint-to-point tunnels are all that is needed. In a 561 multipoint-to-point tunnel, when a packet emerges from the tunnel 562 there is no way to tell which router put the packet into the tunnel. 563 This models the native IP forwarding paradigm, wherein the egress 564 router cannot determine a given packet's ingress router. Of course, 565 point-to-point tunnels might be required for some reason which goes 566 beyond the basic requirements described in this document. E.g., QoS 567 or security considerations might require the use of point-to-point 568 tunnels. So point-to-point tunnels are allowed, but not required, by 569 this framework. 571 If it is desired to use a particular tunneling technology for the 572 softwires, and if that technology has its own "native" signaling 573 methodology, the presumption is that the native signaling will be 574 used. This would certainly apply to MPLS-based softwires, where LDP 575 or RSVP-TE would be used. A softwire based on IPsec would use 576 standard IKE/IPsec signaling, as that is necessary in order to 577 guarantee the softwire's security properties. 579 A Softwire based on GRE might or might not require signaling, 580 depending on whether various optional GRE header fields are to be 581 used. GRE does not have any "native" signaling, so for those cases, 582 a signaling procedure needs to be developed to support Softwires. 584 Another possible softwire technology is L2TPv3. While L2TPv3 does 585 have its own native signaling, that signaling sets up point-to-point 586 tunnels. For the purpose of softwires, it is better to use L2TPv3 in 587 a multipoint-to-point mode, and this requires a different kind of 588 signaling. 590 The signaling to be used for GRE and L2TPv3 to cover these scenarios 591 is BGP-based, and is described in [ENCAPS-SAFI]. 593 If IP-IP tunneling is used, or if GRE tunneling is used without 594 options, no signaling is required, as the only information needed by 595 the ingress AFBR to create the encapsulation header is the IP address 596 of the egress AFBR, and that is distributed by BGP. 598 When the encapsulation IP header is constructed, there may be fields 599 in the IP whose value is determined neither by whatever signaling has 600 been done nor by the distributed routing information. The values of 601 these fields are determined by policy in the ingress AFBR. Examples 602 of such fields may be the TTL field, the DSCP bits, etc. 604 It is desirable for all necessary softwires to be fully set up before 605 the arrival of any packets which need to go through the softwires. 606 That is, the softwires should be "always on". From the perspective 607 of any particular AFBR, the softwire endpoints are always BGP next 608 hops of routes which the AFBR has installed. This suggests that any 609 necessary softwire signaling should be either be done as part of 610 normal system startup (as would happen, e.g., with LDP-based MPLS), 611 or else should be triggered by the reception of BGP routing 612 information (such as is described in [ENCAPS-SAFI]); it is also 613 helpful if distribution of the routing information that serves as the 614 trigger is prioritized. 616 7. Choosing to Forward Through a Softwire 618 The decision to forward through a softwire, instead of to forward 619 natively, is made by the ingress AFBR. This decision is a matter of 620 policy. 622 In many cases, the policy will be very simple. Some useful policies 623 are: 625 - if routing says that an E-IP packet has to be sent out a "core- 626 facing interface" to an I-IP core, send the packet through a 627 softwire 629 - if routing says that an E-IP packet has to be sent out an 630 interface that only supports I-IP packets, then send the E-IP 631 packets through a softwire 633 - if routing says that the BGP next hop address for an E-IP packet 634 is an I-IP address, then send the E-IP packets through a softwire 636 - if the route which is the best match for a particular packet's 637 destination address is a BGP-distributed route, then send the 638 packet through a softwire (i.e., tunnel all BGP-routed packets). 640 More complicated policies are also possible, but a consideration of 641 those policies is outside the scope of this document. 643 8. Selecting a Tunneling Technology 645 The choice of tunneling technology is a matter of policy configured 646 at the ingress AFBR. 648 It is envisioned that in most cases, the policy will be a very simple 649 one, and will be the same at all the AFBRs of a given transit core. 650 E.g., "always use LDP-based MPLS", or "always use L2TPv3". 652 However, other deployments may have a mixture of routers, some of 653 which support, say, both GRE and L2TPv3, but others of which support 654 only one of those techniques. It is desirable therefore to allow the 655 network administration to create a small set of classes, and to 656 configure each AFBR to be a member of one or more of these classes. 657 Then the routers can advertise their class memberships to each other, 658 and the encapsulation policies can be expressed as, e.g., "use L2TPv3 659 to talk to routers in class X, use GRE to talk to routers in class 660 Y". To support such policies, it is necessary for the AFBRs to be 661 able to advertise their class memberships. [ENCAPS-SAFI] specifies a 662 way in which an AFBR may advertise, to other AFBRS, various 663 characteristics which may be relevant to the polcy (e.g., "I belong 664 to class Y"). In many cases, these characteristics can be 665 represented by arbitrarily selected communities or extended 666 communities, and the policies at the ingress can be expressed in 667 terms of these classes (i.e., communities). 669 Policy may also require a certain class of traffic to receive a 670 certain quality of service, and this may impact the choice of tunnel 671 and/or tunneling technology used for packets in that class. This 672 framework allows a variety of tunneling technologies to be used for 673 instantiating softwires. The choice of tunneling technology is a 674 matter of policy, as discussed in section 2. 676 While in many cases the policy will be unconditional, e.g., "always 677 use L2TPv3 for softwires", in other cases the policy may specify that 678 the choice is conditional upon information about the softwire remote 679 endpoint, e.g., "use L2TPv3 to talk to routers in class X, use GRE to 680 talk to routers in class Y". It is desirable therefore to allow the 681 network administration to create a small set of classes, and to 682 configure each AFBR to be a member of one or more of these classes. 683 If each such class is represented as a community or extended 684 community, then [ENCAPS-SAFI] specifies a method that AFBRs can use 685 to advertise their class memberships to each other. 687 This framework also allows for policies of arbitrary complexity, 688 which may depend on characteristics or attributes of individual 689 address prefixes, as well as on QoS or security considerations. 690 However, the specification of such policies is not within the scope 691 of this document. 693 9. Selecting the Softwire for a Given Packet 695 Suppose it has been decided to send a given packet through a 696 softwire. Routing provides the address, in the address family of the 697 transport network, of the BGP next hop. The packet MUST be sent 698 through a softwire whose remote endpoint address is the same as the 699 BGP next hop address. 701 Sending a packet through a softwire is a matter of encapsulating the 702 packet with an encapsulation header that can be processed by the 703 transit network, and then transmitting towards the softwire's remote 704 endpoint address. 706 In many cases, once one knows the remote endpoint address, one has 707 all the information one needs in order to form the encapsulation 708 header. This will be the case if the tunnel technology instantiating 709 the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without 710 optional header fields. 712 If the tunnel technology being used is L2TPv3 or GRE with optional 713 header fields, additional information from the remote endpoint is 714 needed in order to form the encapsulation header. The procedures for 715 sending and receiving this information are described in [ENCAPS- 716 SAFI]. 718 If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, 719 the native signaling procedures of those technologies will need to be 720 used. 722 IPsec procedures will be discussed further in a subsequent revision 723 of this document. 725 RSVP-TE procedures will be discussed in companion documents. 727 If the packet being sent through the softwire matches a route in the 728 labeled IPv4 or labeled IPv6 address families, it should be sent 729 through the softwire as an MPLS packet with the corresponding label. 730 Note that most of the tunneling technologies mentioned in this 731 document are capable of carrying MPLS packets, so this does not 732 presuppose support for MPLS in the core routers. 734 10. Softwire OAM and MIBs 736 10.1. Operations and Maintenance (OAM) 738 Softwires are essentially tunnels connecting routers. If they 739 disappear or degrade in performance then connectivity through those 740 tunnels will be impacted. There are several techniques available to 741 monitor the status of the tunnel end-points (AFBRs) as well as the 742 tunnels themselves. These techniques allow operations such as 743 softwires path tracing, remote softwire end-point pinging and remote 744 softwire end-point liveness failure detection. 746 Examples of techniques applicable to softwire OAM include: 748 o BGP/TCP timeouts between AFBRs 750 o ICMP or LSP echo request and reply addressed to a particular AFBR 752 o [BFD] packet exchange between AFBR routers 754 Another possibility for softwire OAM is to build something similar to 755 the [RFC4378] or in other words creating and generating softwire echo 756 request/reply packets. The echo request sent to a well-known UDP 757 port would contain the egress AFBR IP address and the softwire 758 identifier as the payload (similar to the MPLS forwarding equivalence 759 class contained in the LSP echo request). The softwire echo packet 760 would be encapsulated with the encapsulation header and forwarded 761 across the same path (inband) as that of the softwire itself. 763 This mechanism can also be automated to periodically verify remote 764 softwires end-point reachability, with the loss of reachability being 765 signaled to the softwires application on the local AFBR thus enabling 766 suitable actions to be taken. Consideration must be given to the 767 trade offs between scalability of such mechanisms verses time to 768 detection of loss of endpoint reachability for such automated 769 mechanisms. 771 In general a framework for softwire OAM can for a large part be based 772 on the [RFC4176] framework. 774 10.2. MIBs 776 Specific MIBs do exist to manage elements of the softwire mesh 777 framework. However there will be a need to either extend these MIBs 778 or create new ones that reflect the functional elements that can be 779 SNMP-managed within the softwire network. 781 11. Softwire Multicast 783 A set of client networks, running E-IP, that are connected to a 784 provider's I-IP transit core, may wish to run IP multicast 785 applications. Extending IP multicast connectivity across the transit 786 core can be done in a number of ways, each with a different set of 787 characteristics. Among them are: 789 - Extend each client multicast tree through the transit core, so 790 that for each client tree there is exactly one tree through the 791 core. 793 - Use one multicast tree in the core, add all the AFBRs to it, make 794 it look to the client multicast control protocols as if the 795 transit network is a LAN over which they can run transparently. 797 - Use more than one multicast tree in the core, but less than one 798 per client tree, and perform some kind of aggregation of client 799 trees to core trees. 801 - Don't use any multicast trees in the core, have the ingress AFBRs 802 replicate the multicast traffic and then unicast each replica. 804 This list does not exhaust the set of alternatives. There are also 805 additional issues which are somewhat orthogonal, such as whether it 806 is best for the transit core and the clients to be using the same 807 multicast control protocols or not, what multicast control protocols 808 and service models need to be supported, etc. 810 All these issues will be considered more fully in a subsequent 811 revision of this document. 813 12. Inter-AS Considerations 815 We have so far only considered the case where a "transit core" 816 consists of a single Autonomous System (AS). If the transit core 817 consists of multiple ASes, then it may be necessary to use softwires 818 whose endpoints are AFBRs attached to different Autonomous Systems. 819 In this case, the AFBR at the remote endpoint of a softwire is not 820 the BGP next hop for packets that need to be sent on the softwire. 821 Since the procedures described above require the address of remote 822 softwire endpoint to be the same as the address of the BGP next hop, 823 those procedures do not work as specified when the transit core 824 consists of multiple ASes. 826 There are two ways to deal with this situation. 828 1. Don't do it; require that there be AFBRs at the edge of each 829 AS, so that a transit core does not extend more than one AS. 831 2. Specify a new BGP attribute that allows an AFBR to identify 832 itself without using the NH field. This "next AFBR" attribute 833 would be passed unchanged by non-AFBRs, but each AFBR 834 disseminating a given routing update would replace any existing 835 "next AFBR" attribute by its own address. When an ingress AFBR 836 is choosing a softwire to send a packet through, if a "next 837 AFBR" attribute is present, it would use that rather than the 838 next hop to help it choose the proper softwire. 840 13. Security Considerations 842 Security for softwire signaling can be achieved using BGP/TCP MD5- 843 keying. The softwire data plane can employ encryption of the data 844 packets using Ipsec. This will be explained in a companion document. 846 [RFC4111] outlines the L3VPN security framework which in many cases 847 is directly applicable to the softwire mesh framework. 849 14. Acknowledgments 851 David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, 852 Mingwei Xu and Ke Xu provided useful input into this document. 854 15. Normative References 856 [ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation 857 Attribute", P. Mohapatra and E. Rosen, draft-pmohapat-idr-info-safi- 858 00.txt, September 2006. 860 [RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996. 862 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 863 S. Bradner, March 1997. 865 [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, 866 S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000. 868 [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. 869 Viswanathan, R. Callon, RFC 3031, January 2001. 871 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. 872 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, RFC 3032, 873 January 2001. 875 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. 876 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 877 December 2001. 879 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 880 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 882 [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI 883 with an IPv6 Next Hop", draft-lefaucheur-idr-v4nlri-v6nh-00.txt, 884 October 2006. 886 [V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, 887 "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge 888 Routers (6PE)", RFC 4798, February 2007. 890 16. Informative References 892 [RFC1195] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual 893 Environments", RFC 1195, December 1990. 895 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998 897 [RFC3036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman, 898 A. Fredette, B. Thomas, January 2001. 900 [RFC4111] L. Fang, "Security Framework for Provider-Provisioned 901 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 903 [RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A. 904 Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) 905 Operations and Management", RFC 4176, October 2005. 907 [RFC4271] Rekhter, Y,, Li T., Hares, S., "A Border Gateway Protocol 4 908 (BGP-4)", RFC 4271, January 2006. 910 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 911 Networks (VPNs)", RFC 4364, February 2006. 913 [RFC4378] D. Allan and T. Nadeau, "A Framework for Multi-Protocol 914 Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, 915 February 2006. 917 [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", 918 draft-ietf-bfd-base-04 (work in progress), October 2005. 920 [SW-PROB] X. Li, "Softwire Problem Statement", draft-ietf-softwire- 921 problem-statement-00.txt, December 2005. 923 Authors' Addresses 924 Jianping Wu 925 Tsinghua University 926 Department of Computer Science, Tsinghua University 927 Beijing 100084 928 P.R.China 930 Phone: +86-10-6278-5983 931 Email: jianping@cernet.edu.cn 933 Yong Cui 934 Tsinghua University 935 Department of Computer Science, Tsinghua University 936 Beijing 100084 937 P.R.China 939 Phone: +86-10-6278-5822 940 Email: yong@csnet1.cs.tsinghua.edu.cn 942 Xing Li 943 Tsinghua University 944 Department of Electronic Engineering, Tsinghua University 945 Beijing 100084 946 P.R.China 948 Phone: +86-10-6278-5983 949 Email: xing@cernet.edu.cn 951 Chris Metz 952 Cisco Systems, Inc. 953 3700 Cisco Way 954 San Jose, Ca. 95134 955 USA 957 Email: chmetz@cisco.com 958 Eric C. Rosen 959 Cisco Systems, Inc. 960 1414 Massachusetts Avenue 961 Boxborough, MA, 01719 962 USA 964 Email: erosen@cisco.com 966 Simon Barber 967 Cisco Systems, Inc. 968 250 Longwater Avenue 969 Reading, ENGLAND, RG2 6GB 970 United Kingdom 972 Email: sbarber@cisco.com 974 Pradosh Mohapatra 975 Cisco Systems, Inc. 976 3700 Cisco Way 977 San Jose, Ca. 95134 978 USA 980 Email: pmohapat@cisco.com 982 John Scudder 983 Juniper Networks 984 1194 North Mathilda Avenue 985 Sunnyvale, California 94089 986 USA 988 Email: jgs@juniper.net 990 17. Full Copyright Statement 992 Copyright (C) The IETF Trust (2007). 994 This document is subject to the rights, licenses and restrictions 995 contained in BCP 78, and except as set forth therein, the authors 996 retain all their rights. 998 This document and the information contained herein are provided on an 999 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1000 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1001 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1002 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1003 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1004 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1006 18. Intellectual Property 1008 The IETF takes no position regarding the validity or scope of any 1009 Intellectual Property Rights or other rights that might be claimed to 1010 pertain to the implementation or use of the technology described in 1011 this document or the extent to which any license under such rights 1012 might or might not be available; nor does it represent that it has 1013 made any independent effort to identify any such rights. Information 1014 on the procedures with respect to rights in RFC documents can be 1015 found in BCP 78 and BCP 79. 1017 Copies of IPR disclosures made to the IETF Secretariat and any 1018 assurances of licenses to be made available, or the result of an 1019 attempt made to obtain a general license or permission for the use of 1020 such proprietary rights by implementers or users of this 1021 specification can be obtained from the IETF on-line IPR repository at 1022 http://www.ietf.org/ipr. 1024 The IETF invites any interested party to bring to its attention any 1025 copyrights, patents or patent applications, or other proprietary 1026 rights that may cover technology that may be required to implement 1027 this standard. Please address the information to the IETF at ietf- 1028 ipr@ietf.org.