idnits 2.17.1 draft-ietf-l2vpn-ipls-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document 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 (October 30, 2014) is 3465 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (ref. 'PWE3-CONTROL') (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Working Group Himanshu Shah 3 Internet-Draft Ciena Corp 4 Intended Status: Historic 5 Eric Rosen 6 Francois Le Faucheur 7 Giles Heron 8 Cisco Systems 9 October 30, 2014 11 IP-Only LAN Service (IPLS) 12 draft-ietf-l2vpn-ipls-16.txt 14 Status of this Memo 16 This document is not an Internet Standards Track specificaion; it 17 is published for the historical record. 19 This document defines a Historic Document for the Internet 20 community. This document is a product of the Internet Engineering 21 Task Force (IETF). It represents the consensus of the IETF 22 community. It has received public review and has been approved for 23 publication by the Internet Engineering Steering Group (IESG). 24 Not all documents approved by the IESG are a candidate for any 25 level of Internet Standard; see section 2 of RFC 5741. 27 Information about the current status of this document, any errata, 28 and how to provide feedback on it may be obtained at 29 http://www.rfc-editor.org/info/rfc6348. 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on April 30, 2015 51 Internet Draft draft-ietf-l2vpn-ipls-16.txt 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Abstract 70 A Virtual Private LAN Service (VPLS) is used to interconnect 71 systems across a wide-area or metropolitan-area network, making it 72 appear that they are on a private LAN. The systems which are 73 interconnected may themselves be LAN switches. If, however, they 74 are IP hosts or IP routers, certain simplifications to the operation 75 of the VPLS are possible. We call this simplified type of VPLS an 76 "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN 77 interfaces are run in promiscuous mode, and frames are forwarded 78 based on their destination MAC addresses. However, the maintenance 79 of the MAC forwarding tables is done via signaling, rather than via 80 the MAC address learning procedures specified in [IEEE 802.1D]. 81 This draft specifies the protocol extensions and procedures for 82 support of the IPLS service. 84 The original intent was to provide an alternate solution to VPLS 85 for those PE routers that were not capable of learning MAC address 86 through data plane. This became a non-issue with newer hardware. 87 The concepts put forth by this draft are still valuable and are 88 adopted in one form or other by newer work such as Ethernet VPN 89 in L2VPN Working Group and possible data center applications. At 90 this point, no further action is planned to update this document 91 and is published simply as a historic record of the ideas. 93 Conventions 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 RFC 2119. 99 Internet Draft draft-ietf-l2vpn-ipls-16.txt 101 Table of Contents 103 Copyright Notice .................................................... 1 104 Abstract.............................................................. 2 105 1.0 Contributing Authors ............................................. 3 106 2.0 Overview.......................................................... 4 107 2.1 Terminology ..................................................... 7 108 3.0 Topology.......................................................... 8 109 4.0 Configuration..................................................... 9 110 5.0 Discovery........................................................ 10 111 5.1 CE discovery ................................................... 10 112 5.1.1 IPv4 based CE discovery ..................................... 10 113 5.1.2 Ipv6 based CE discovery [RFC 4861] .......................... 10 114 6.0 Pseudowire Creation.............................................. 11 115 6.1 Receive Unicast Multipoint-to-point Pseudowire ................. 11 116 6.2 Receive Multicast Multipoint-to-point Pseudowire ............... 11 117 6.3 Send Multicast Replication tree ................................ 12 118 7.0 Signaling........................................................ 13 119 7.1 IPLS PW Signaling .............................................. 13 120 7.2 IPv6 Capability Advertisement .................................. 17 121 7.3 Signaling Advertisement Processing ............................. 18 122 8. IANA Considerations............................................... 19 123 8.1. LDP Status messages ........................................... 19 124 8.2. Interface Parameters .......................................... 19 125 9.0 Forwarding....................................................... 19 126 9.1 Non-IP or non-ARP traffic ...................................... 19 127 9.2 Unicast IP Traffic ............................................. 20 128 9.3 Broadcasts and Multicast IP Traffic ............................ 20 129 9.4 ARP Traffic .................................................... 20 130 9.6 Encapsulation .................................................. 23 131 10.0 Attaching to IPLS via ATM or FR............................... 23 132 11.0 VPLS vs IPLS.................................................... 23 133 12.0 IP Protocols.................................................... 24 134 13.0 Dual Homing with IPLS........................................... 25 135 14.0 Proxy ARP function.............................................. 25 136 14.1 ARP Proxy - Responder ......................................... 25 137 14.2 ARP Proxy - Generator ......................................... 25 138 15.0 Data Center Applicability ...................................... 25 139 16.0 Acknowledgements................................................ 26 140 17.0 Security Considerations......................................... 27 141 17.1 Control plane security ........................................ 27 142 17.2 Data plane security ........................................... 28 143 18.0 References...................................................... 29 144 18.1 Normative References .......................................... 29 145 18.2 Informative References ........................................ 29 146 19.0 Author's Address................................................ 30 148 1.0 Contributing Authors 149 Internet Draft draft-ietf-l2vpn-ipls-16.txt 151 This document is the combined effort of the following individuals 152 and many others who have carefully reviewed this document and 153 provided the technical clarifications. 155 K. Arvind Fortress 156 Vach Kompella/Mathew Bocci Alcatel/Lucent 157 Shane Amante Apple 159 2.0 Overview 161 As emphasized in [VPLS], Ethernet has become popular as an access 162 technology in Metropolitan and Wide Area Networks. [VPLS] describes 163 how geographically dispersed customer LANs can be interconnected 164 over a service provider's network. The VPLS service is provided by 165 Provider Edge (PE) devices that connect Customer Edge (CE) devices. 166 The VPLS architecture provides this service by incorporating 167 bridging functions such as MAC address learning in the PE devices. 169 Provider Edge platforms are designed primarily to be IP routers, 170 rather than to be LAN switches. To add VPLS capability to a PE 171 router, one has to add MAC address learning capabilities, along with 172 aging and other mechanisms native to Ethernet switches. This may be 173 fairly complex to add to the forwarding plane architecture of an IP 174 router. As discussed in [L2VPN-FWK], in scenarios where the CE 175 devices are NOT LAN switches, but rather are IP hosts or IP routers, 176 it is possible to provide the VPLS service without requiring MAC 177 address learning and aging on the PE. Instead, a PE router has to 178 have the capability to match the destination MAC address in a packet 179 received from a CE to an outbound pseudowire. The requirements for 180 the IPLS service are described in [L2VPN-REQTS]. The purpose of this 181 document is to specify a solution optimized for IPLS. 183 IPLS provides a VPLS-like service using PE routers that are not 184 designed to perform general LAN bridging functions. One must be 185 willing to accept the restriction that an IPLS be used for IP 186 traffic only, and not used to interconnect CE devices that are 187 themselves LAN switches. This is an acceptable restriction in many 188 environments, given that IP is the predominant type of traffic in 189 today's networks. 191 The original intent was to provide an alternate solution to VPLS 192 for those PE routers that were not capable of learning MAC address 193 through data plane. This became non-issue with newer hardware. 194 The concepts put forth by this draft are still valuable and are 195 adopted in one form or other by newer work such as Ethernet VPN 196 in L2VPN Working Group and possible data center applications. At 197 this point, no further action is planned to update this document 198 and is published simply as a historic record of the ideas. 200 Internet Draft draft-ietf-l2vpn-ipls-16.txt 202 In IPLS, a PE device implements multi-point LAN connectivity for IP 203 traffic using the following key functions: 205 1. CE Address Discovery: Each Provider Edge (PE) device discovers 206 MAC address of the locally attached Customer Edge (CE) IP 207 devices, for each IPLS instance configured on the PE device. In 208 some configurations, PE also learns the IP address of the CE 209 device (when performing ARP proxy functions, described later in 210 the document). 212 2. Pseudowire (PW) for Unicast Traffic: For each locally attached 213 CE device in a given IPLS instance, a PE device sets up a 214 pseudowire (PW-LSP) to each of the other PEs that supports the 215 same IPLS instance. 217 For instance, if PEx and PEy both support IPLS I, and PEy is 218 locally attached to CEa and CEb, PEy will initiate the setup of 219 two pseudowires between itself and PEx. One of these will be 220 used to carry unicast traffic from any of PEx's CE devices to 221 CEa. The other will be used to carry unicast traffic from any 222 of PEx's CE devices to CEb. 224 Note that these pseudowires carry traffic only in one 225 direction. Further, while the pseudowire implicitly identifies 226 the destination CE of the traffic, it does not identify the 227 source CE; packets from different source CEs bound to the same 228 destination CE are sent on a single pseudowire. 230 3. Pseudowires for Multicast Traffic: In addition, every PE 231 supporting a given IPLS instance will set up a special 232 'multicast pseudowire' to every other PE in that IPLS instance. 233 If, in the above example, one of PEx's CE devices sends a 234 multicast packet, PEx would forward the multicast packet to PEy 235 on the special 'multicast' pseudowire. PEy would then send a 236 copy of that packet to CEa and a copy to CEb. 238 The 'multicast' pseudowire carries Ethernet frames of 239 multicast/broadcast IP, ARP and ICMP (Inverse) Neighbor 240 Discovery (ND/IND) packets for IPv6. Thus when a PE sends a 241 multicast packet across the network, it sends one copy to each 242 remote PE (supporting the given IPLS instance). If a 243 particular remote PE has more than one CE device in that IPLS 244 instance, the remote PE must replicate the packet and send one 245 copy to each of its local CEs. 247 As with the pseudowires that are used for unicast traffic, 248 packets travel in only one direction on these pseudowires, and 249 packets from different sources may be freely intermixed. 251 Internet Draft draft-ietf-l2vpn-ipls-16.txt 253 4. Signaling: The necessary pseudowires can be set up and 254 maintained using the LDP-based signaling procedures described 255 in [PWE3-CONTROL]. 257 A PE may assign the same label to each of the unicast 258 pseudowires that lead to a given CE device, in effect creating 259 a multipoint-to-point pseudowire. 261 Similarly, a PE may assign the same label to each of the 262 'multicast' pseudowires for a given IPLS instance, in effect 263 creating a multipoint-to-point pseudowire. 264 When setting up a pseudowire to be used for unicast traffic, 265 the PE must also signal the MAC address of the corresponding CE 266 device. It should also, optionally, advertise IP address of the 267 local CE device, especially when ARP proxy function is 268 configured or simply for operational management purposes. 269 Similarly, for IPv6 support, PE may optionally advertise the 270 IPv6 addresses of the local CE device. 272 5. ARP Packet Forwarding: ARP packets [ARP] are forwarded from 273 attachment circuit (AC) to 'multicast' pseudowires in the 274 Ethernet frame format as described by [PWE3-ETH].The following 275 rules are observed when processing ARP packets, 276 a. Both broadcast (request) and unicast (response) ARP 277 packets are sent over the 'multicast' pseudowire. 278 b. When an ARP packet is received from an AC, the packet is 279 copied to control plane for learning MAC address of the 280 CE. Optionally, IP address is also learned to record the 281 association of IP and MAC address. 282 c. All Ethernet packets, including ARP packets, received from 283 'multicast' pseudowire are forwarded out to all the ACs 284 associated with the IPLS instance. These packets are not 285 copied to control plane. 287 6. ICMP IPv6 ND/IND related Packet Forwarding: (Inverse) Neighbor 288 Discovery (ND/IND) IPv6 packets from an AC are replicated and a 289 copy is sent to other ACs and to 'multicast' PWs associated 290 with the IPLS instance in the native Ethernet format, 291 unchanged. A copy is also submitted to Control Plane to learn 292 the MAC address and optionally corresponding IPv6 addresses. 294 7. Multicast IP packet forwarding: An IP Ethernet frame received 295 from an AC is replicated to other ACs and the 'multicast' 296 pseudowires associated with the IPLS instance. An IP Ethernet 297 frame received from a 'multicast' pseudowire is replicated to 298 all the egress ACs associated with the IPLS instance. 300 Internet Draft draft-ietf-l2vpn-ipls-16.txt 302 8. Unicast IP packet forwarding: An IP packet received from the AC 303 is forwarded based on the MAC DA lookup in the forwarding 304 table. If a match is found, the packet is forwarded to the 305 associated egress interface. If the egress interface is unicast 306 pseudowire, the packet is sent without MAC header. If the 307 egress interface is a local AC the Ethernet frame is forwarded 308 as such. An IP packet received from the unicast pseudowire is 309 forwarded to egress AC with MAC header prepended. The MAC DA is 310 derived from the forwarding table while MAC SA is the MAC 311 address of the PE. 313 Both VPLS [VPLS] and IPLS require the ingress PE to forward a frame 314 based on its destination MAC address. However, two key differences 315 between VPLS and IPLS can be noted from the above description: 317 . In VPLS, MAC entries are placed in the Forwarding Information 318 Base (FIB) of the ingress PE as a result of MAC address 319 learning (which occurs in the data plane) while in IPLS MAC 320 entries are placed in the FIB as a result of pseudowire 321 signaling operations (control plane). 322 . In VPLS, the egress PE looks up a frame's destination MAC 323 address to determine the egress AC; in IPLS, the egress AC is 324 determined entirely by the ingress PW-label. 326 The following sections describe the details of the IPLS scheme. 328 2.1 Terminology 330 IPLS IP-only LAN service (a type of Virtual Private 331 LAN Service that is restricted to IP traffic 332 only). 334 mp2p PW Multipoint-to-Point Pseudowire. A pseudowire 335 that carries traffic from remote PE devices to 336 a PE device that signals the pseudowire. The 337 signaling PE device advertises the same PW- 338 label to all remote PE devices that participate 339 in the IPLS service instance. In IPLS, for a 340 given IPLS instance, an mp2p PW used for IP 341 unicast traffic is established by a PE for each 342 CE device locally attached to that PE. It is a 343 unidirectional tree whose leaves consist of the 344 remote PE peers (which connect at least one AC 345 associated with the same IPLS instance) and 346 whose root is the signaling PE. Traffic flows 347 from the leaves towards the root. 349 Multicast PW Multicast/broadcast Pseudowire. A special kind 350 of mp2p PW that carries IP multicast/broadcast 351 traffic, all ARP frames and ICMP (I)ND frames 352 for IPv6. In the IPLS architecture, for each 353 IPLS instance supported by a PE, that PE device 354 establishes exactly one multicast PW. Multicast 355 PW uses Ethernet encapsulation. 357 Internet Draft draft-ietf-l2vpn-ipls-16.txt 359 Unicast PW Unicast Pseudowire carries IP unicast packets. 360 A PE creates unicast PW for each locally 361 attached CE. The unicast PW uses IP Layer2 362 transport encapsulation. 364 CE Customer Edge device. In this document, a CE is 365 any IP node (host or router) connected to the 366 IPLS LAN service. 368 Replication Tree The collection of all multicast PWs and ACs 369 that are members of an IPLS service instance on 370 a given PE. When a PE receives a 371 multicast/broadcast packet from an AC, the PE 372 device sends a copy of the packet to every 373 multicast pseudowire and AC of the replication 374 tree, excluding the AC on which the packet was 375 received. When a PE receives a packet from a 376 multicast PW, the PE device sends a copy of the 377 packet to all the ACs of the replication tree 378 and never to other PWs. 380 (I)ND (Inverse) Neighbor Discovery in IPv6 uses ICMP 381 packets. It is a protocol that uses Neighbor 382 solicitation/Advertisement PDUs. 384 RS Router Solicitation. Hosts generate all router 385 multicast ICMP packet to discover IPv6 router 386 on the local link. 388 RA Router Advertisement. Router generates all 389 multicast ICMP packet to advertise its presence 390 on the link. A unicast response is also sent 391 when RS is received. 393 NS Neighbor Solicitation in IPv6 uses (multicast) 394 ICMP packets to resolve IPv6 interface address 395 to MAC address association. 397 NA Neighbor Advertisement in IPv6 uses (unicast) 398 ICMP packets to respond to NS. 400 3.0 Topology 402 The Customer Edge (CE) devices are IP nodes (hosts or routers) that 403 are connected to PE devices either directly, or via an Ethernet 404 network. We assume that the PE/CE connection may be regarded by the 405 PE as an "interface" to which one or more CEs are attached. This 406 interface may be a physical LAN interface or a VLAN. The Provider 407 Edge (PE) routers are MPLS Label Edge Routers (LERs) that serve as 408 pseudowire endpoints. 410 Internet Draft draft-ietf-l2vpn-ipls-16.txt 412 +----+ +----+ 413 + S1 +---+ ........................... +---| S2 | 414 +----+ | | . . | +----+ 415 IPa | | +----+ +----+ | IPe 416 + +---| PE1|---MPLS and/or IP---| PE2|---+ 417 / \ +----+ |Network +----+ | 418 +----+ +---+ . | . | +----+ 419 + S1 + | S1| . +----+ . +---| S2 | 420 +----+ +---+ ..........| PE3|........... +----+ 421 IPb IPc +----+ IPf 422 | 423 | 424 +----+ 425 | S3 | 426 +----+ 427 IPd 429 In the above diagram, an IPLS instance is shown with three sites: 430 site S1, site S2 and site S3. In site S3, the CE device is directly 431 connected to its PE. In the other two sites, there are multiple CEs 432 connected to a single PE. More precisely, the CEs at these sites are 433 on an Ethernet (switched at site 1 and shared at site 2) network (or 434 VLAN), and the PE is attached to that same Ethernet network or 435 VLAN). We impose the following restriction: if one or more CEs 436 attach to a PE by virtue of being on a common LAN or VLAN, there 437 MUST NOT be more than one PE on that LAN or VLAN. 439 PE1, PE2 and PE3 are shown as connected via an MPLS network; 440 however, other tunneling technologies, such as GRE, L2TPv3, etc., 441 could also be used to carry the pseudowires. 443 An IPLS instance is a single broadcast domain, such that each IP end 444 station (e.g., IPa) appears to be co-located with other IP end 445 stations (e.g., IPb through IPf) on the same subnet. The IPLS 446 service is transparent to the CE devices and requires no changes to 447 them. 449 4.0 Configuration 451 Each PE router is configured with one or more IPLS service 452 instances, and each IPLS service instance is associated with a 453 unique VPN-Id. For a given IPLS service instance, a set of ACs is 454 identified. Each AC can be associated with only one IPLS instance. 455 An AC, in this document, is either a customer-facing Ethernet port, 456 or a particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a 457 customer-facing Ethernet port. 459 The PE router can optionally be configured with a local MAC address 460 to be used as source MAC address when IP packets are forwarded from 461 Internet Draft draft-ietf-l2vpn-ipls-16.txt 463 a pseudowire to an AC. By default, a PE uses the MAC address of the 464 customer-facing Ethernet interface for this purpose. 466 5.0 Discovery 468 The discovery process includes: 469 . Remote PE discovery 470 . VPN (i.e., IPLS) membership discovery 471 . IP CE end station discovery 473 This draft does not discuss the remote PE discovery or VPN 474 membership discovery. This information can either be user configured 475 or can be obtained using auto-discovery techniques described in 476 [L2VPN-SIG] or other methods. However, the discovery of the CE is an 477 important operational step in the IPLS model and is described below. 479 5.1 CE discovery 481 Each PE actively detects the presence of local CEs by snooping IP 482 and ARP frames received over the ACs. When an AC configured in an 483 IPLS instance becomes operational, it enters the CE discovery phase. 484 In this phase, the PE examines each multicast/broadcast Ethernet 485 frame. For link-local IP frames (for example IGP 486 discovery/multicast/broadcast packets typically 224.0.0.x addresses 487 [RFC-1112]), the CE's (source) MAC address is extracted from the 488 Ethernet header and the (source) IP address is obtained from the IP 489 header. 491 For each CE, the PE maintains the following tuple: . 495 5.1.1 IPv4 based CE discovery 497 As indicated earlier, a copy of ARP frames received over the AC is 498 submitted to the control plane. The PE learns MAC address and 499 optionally IP address of the CE from the source address fields of 500 the ARP PDU. 502 Once a CE is discovered, its status is monitored continuously by 503 examining the received ARP frames and by periodically generating ARP 504 requests. The absence of an ARP response from a CE after a 505 configurable number of ARP requests is interpreted as loss of 506 connectivity with the CE. 508 5.1.2 Ipv6 based CE discovery [RFC 4861] 510 A copy of Neighbor and Router Discovery frames received over the AC 511 are submitted to the control plane in the PE. 513 Internet Draft draft-ietf-l2vpn-ipls-16.txt 515 If the PE receives a Neighbor Solicitation message, and the source 516 IP address of the message is not the unspecified address, the PE 517 learns the MAC address and optionally IP address of the CE. 519 If the PE receives an unsolicited Neighbor Advertisement message, 520 the PE learns the source MAC address and optionally the IP address 521 of the CE. 523 If the PE receives a Router Solicitation, and the source IP address 524 of the message is not the unspecified address, the PE learns source 525 MAC address and optionally the IP address of the CE. 527 If the PE receives a Router Advertisement, it learns source MAC 528 address and optionally the IP address of the CE. 530 The PE will periodically generate Neighbor Solicitation messages for 531 the IP address of the CE as a means of verifying the continued 532 existence of the address and its MAC address binding. The absence of 533 a response from the CE device for a given number of retries could be 534 interpreted as a loss of connectivity with the CE. 536 6.0 Pseudowire Creation 538 6.1 Receive Unicast Multipoint-to-point Pseudowire 540 As the PE discovers each locally attached CE, a unicast multipoint- 541 to-point pseudowire (mp2p PW) associated exclusively with that CE is 542 created by distributing the MAC address and optionally IP address of 543 the CE along with a PW-Label to all the remote PE peers that 544 participate in the same IPLS instance. Note that the same value of a 545 PW-label SHOULD be distributed to all the remote PE peers for a 546 given CE. The mp2p PW thus created is used by remote PEs to send 547 unicast IP traffic to a specific CE. 549 (The same functionality can be provided by a set of point-to-point 550 PWs, and the PE is not required to send the same PW-label to all the 551 other PEs. For convenience, however, we will use the term mp2p PWs, 552 which may be implemented using a set of point-to-point PWs.) 554 The PE forwards a frame received over this mp2p PW to the associated 555 AC. 557 The unicast pseudowire uses IP Layer2 Transport encapsulation as 558 define in [PWE3-CONTROL]. 560 6.2 Receive Multicast Multipoint-to-point Pseudowire 562 When a PE is configured to participate in an IPLS instance, it 563 advertises a 'multicast' PW-label to every other PE that is a member 564 Internet Draft draft-ietf-l2vpn-ipls-16.txt 566 of the same IPLS. The advertised PW-label value is the same for each 567 PE, which creates an mp2p pseudowire. There is only one such 568 multicast mp2p PW per PE for each IPLS instance and this pseudowire 569 is used exclusively to carry IP multicast/broadcast, ARP traffic and 570 (inverse) Neighbor Discovery packets for IPv6 from the remote PEs to 571 this PE for this IPLS instance. 573 Note that no special functionality is expected from this pseudowire. 574 We call it a 'multicast' pseudowire because we use it to carry 575 multicast and broadcast IP, ARP and IPv6 Neighbor Discovery traffic. 576 The pseudowire itself need not provide any different service than 577 any of the unicast pseudowires. 579 In particular, the Receive multicast mp2p PW does not perform any 580 replication of frames itself. Rather, it is there to signify to the 581 PE that the PE may need to replicate a copy of a frame received over 582 this mp2p PW onto all the AC that are associated with the IPLS 583 instance of the mp2p PW. 585 The multicast mp2p pseudowire is considered the principle pseudowire 586 in the bundle of mp2p pseudowires that consist of one multicast mp2p 587 pseudowire and a variable number of unicast mp2p pseudowires for a 588 given IPLS instance. In a principle role, multicast PW represents 589 the IPLS instance. The life of all unicast PWs in the IPLS instance 590 depends on the existence of the multicast PW. If, for some reasons, 591 multicast PW cease to exist, all the associated unicast pseudowires 592 in the bundle are removed. 594 The multicast pseudowire uses Ethernet encapsulation as defined in 595 [PWE3-ETH]. 597 The use of pseudowires which are specially optimized for multicast 598 is for further study. 600 6.3 Send Multicast Replication tree 602 The PE creates a send replication tree for each IPLS instance, which 603 consists of the collection of all ACs and all the 'multicast' 604 pseudowires of the IPLS instance. 606 Any ARP, Neighbor Discovery or multicast IP Ethernet frame received 607 over an AC is replicated to the other ACs and to the mp2p multicast 608 pseudowire of the send replication tree. The send replication tree 609 deals mostly with broadcast/multicast Ethernet MAC frames. One 610 exception to this is unicast ARP and IPv6 Neighbor Discovery frame, 611 the processing of which is described in the following section. 613 Any Ethernet frame received over the multicast PW is replicated to 614 all the ACs of the send replication tree of the IPLS instance 615 associated with the incoming PW label. One exception is unicast ARP 616 Internet Draft draft-ietf-l2vpn-ipls-16.txt 618 and Neighbor Discovery frame used for IPv6, the processing of which 619 is described in the following section. 621 7.0 Signaling 623 [PWE3-CONTROL] uses the Label Distribution Protocol (LDP) to 624 exchange PW-FECs in the Label Mapping message in a downstream 625 unsolicited mode. The PW-FEC comes in two forms; PWid and 626 Generalized PWid FEC elements. These FEC elements define some fields 627 that are common between them. The discussions below refer to these 628 common fields for IPLS related extensions. Note that the use of 629 multipoint to point and unidirectional characteristics of the PW 630 makes BGP as the ideal candidate for PW-FEC signaling. The use of 631 BGP for such purposes is for future study. 633 7.1 IPLS PW Signaling 635 An IPLS carries IP packets as payload over its unicast pseudowires 636 and Ethernet packet as payload over its multicast pseudowire. The 637 PW-type to be used for unicast pseudowire is the IP PW, defined in 638 [PWE3-CONTROL] as IP Layer2 Transport. The PW-type to be used for 639 multicast pseudowire is the Ethernet PW as defined in [PWE3-ETH]. 640 The PW-Type values for these encapsulations are defined in [PWE3- 641 IANA]. 643 When processing a received PW FEC, the PE matches the PW Id with the 644 locally configured PW Id for the IPLS instance. If the PW type is 645 Ethernet, the PW-FEC is for multicast PW. If the PW type is 'IP 646 Layer2 transport', the PW FEC is for unicast PW. 648 For unicast PW, PE must check the presence of MAC address TLV in the 649 optional parameter fields of the Label Mapping message. If this 650 parameter is absent, a Label Release message must be issued with a 651 Status Code meaning "MAC Address of the CE is absent" [note: Status 652 Code 0x000000XX is pending IANA allocation], to reject the 653 establishment of the unicast PW with the remote PE. 655 The PE may optionally include IP address TLV based on the user 656 configuration for advertising of the IP addresses of the local CE. 658 The processing of the address list TLV is as follows. 660 o If a pseudowire is configured for AC with IPv4 CEs only, the 661 PE should advertise address list tlv with address family type 662 to be of IPv4 address. The PE should process the IPv4 address 663 list TLV as described in this document. 664 o If a pseudowire is configured for AC with both IPv4 and IPv6 665 CEs, the PE should advertise IPv6 capability using the 666 procedures described in Section below. 668 Internet Draft draft-ietf-l2vpn-ipls-16.txt 670 o If a PE does not receive any IP address list TLV or IPv6 671 capability advertisement, it MAY assume IPv4 behavior. 673 The IPLS uses the Address List TLV as defined in [RFC 5036] to 674 signal the MAC (and optionally IP) address of the local CE. There 675 are two TLVs defined below; IP Address TLV and MAC Address TLV. MAC 676 address TLV must be included in the optional parameter field of the 677 Label Mapping message when establishing the unicast IP PW for IPLS. 679 When configured to support specific type of IP traffic (IPv4 or 680 IPv6), the PE augments verification of the type of traffic PW will 681 carry using the Address Family Type value. If there is a mismatch 682 between the received Address Family value and the expectation of 683 IPLS instance to which the PW belongs, the PE must issue a Label 684 Release message with a Status Code meaning "IP Address type 685 mismatch" (Status Code 0x0000004A) to reject the PW establishment. 687 Encoding of the IP Address TLV is: 689 0 1 2 3 690 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |0|0| Address List (0x0101) | Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Address Family | CE's IP Address | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | CE's IP Address | | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 Length 700 When Address Family is IPV4, Length is equal to 6 bytes; 701 2 bytes for address family and 4 bytes of IP address. The 702 length is 18 bytes when address family is IPv6, 2 bytes for 703 address family and 16 bytes of IP address. 705 Address Family 706 Two octet quantity containing a value from the ADDRESS FAMILY 707 NUMBERS from ADDRESS FAMILY NUMBERS in [ADDR-IANA] that encodes 708 the addresses contained in the Addresses field. 710 IP Address of the CE 711 IP address of the CE attached to the advertising PE. The 712 encoding of the individual address depends on the Address 713 Family. 715 The following address encodings are defined by this version of the 716 protocol: 718 Address Family Address Encoding 720 IPv4 (1) 4 octet full IPv4 address 722 Internet Draft draft-ietf-l2vpn-ipls-16.txt 724 IPv6 (2) 16 octet full IPv6 address 726 Note that more than one instance of the IP address TLV may exist, 727 especially when support for IPv6 is configured. 729 Internet Draft draft-ietf-l2vpn-ipls-16.txt 731 Encoding of the MAC Address TLV is: 733 0 1 2 3 734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |0|0| Address List (0x0101) | Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Address Family | CE's MAC address | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Length 744 The length field is set to value 8 (2 for address family, 6 for 745 MAC address) 747 Address Family 748 Two octet quantity containing a value from ADDRESS FAMILY 749 NUMBERS in [ADDR-IANA] that encodes the addresses contained in 750 the Addresses field. 752 CE's MAC Address 753 MAC address of the CE attached to the advertising PE. The 754 encoding of the individual address depends on the Address 755 Family. 757 The following address encodings are defined by this version of the 758 protocol: 760 Address Family Address Encoding 762 MAC (6) 6 octet full Ethernet MAC address 764 The IPv4 address of the CE is also supplied in the optional 765 parameters field of the LDP Notification message along with the PW 766 FEC. The LDP Notification message is used to signal any change in 767 the status of the CE's IPv4 address. 769 Note that Notification message does not apply to MAC address TLV 770 since an update to MAC address of the CE should result in label 771 withdraw followed by establishment of new PW with new MAC address of 772 the CE. However, advertisement of IP address(es) of the CE is 773 optional and changes may become known after the establishment of 774 unicast PW. 776 Internet Draft draft-ietf-l2vpn-ipls-16.txt 778 The encoding of the LDP Notification message is as follows. 780 0 1 2 3 781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |0| Notification (0x0001) | Message Length | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Message ID | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Status (TLV) | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | IP Address List TLV (as defined above) | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | PWId FEC or Generalized ID FEC | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 The Status TLV status code is set to 0x0000002C "IP address of CE", 795 to indicate that IP Address update follows. Since this notification 796 does not refer to any particular message the Message Id, and Message 797 Type fields are set to 0. 799 The PW FEC TLV SHOULD NOT include the interface parameters as they 800 are ignored in the context of this message. 802 7.2 IPv6 Capability Advertisement 804 A 'Stack Capability' Interface Parameter sub-TLV is signaled by the 805 two PEs so that they can agree which stack(s) they should be using. 806 It is assumed by default that the IP PW will always be capable of 807 carrying IPv4 packets. Thus this capability sub-TLV is used to 808 indicate if other stacks need to be supported concurrently with 809 IPv4. 811 The 'Stack Capability' sub-TLV is part of the interface parameters 812 of the PW FEC. The proposed format for the Stack Capability 813 interface parameter sub-TLV is as follows: 815 0 1 2 3 816 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Parameter ID | Length | Stack Capability | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Parameter ID = 0x16 823 Length = 4 825 Stack capability = 0x000X to indicate IPv6 stack capability 826 Internet Draft draft-ietf-l2vpn-ipls-16.txt 828 The Value of Stack capability is dependent on the PW type context. 829 For IP PW type, a setting of 0x000X indicates IPv6 stack capability. 831 A PE that supports IPv6 on an IP PW MUST signal the stack capability 832 sub-TLV in the initial label mapping message for the PW. The PE 833 nodes compare the value advertised by the remote PE with the local 834 configuration and only use a capability which is advertised by both. 835 If a PE that supports IPv6 does not receive a 'stack capability' 836 sub-TLV from the far-end PE in the initial label mapping message, or 837 one is received but it is set to a reserved value, the PE MUST send 838 an unsolicited release for the PW label with the LDP status code 839 meaning "IP Address type mismatch" (Status Code 0x0000004A). 841 The behavior of a PE that does not understand an interface parameter 842 sub-TLV is specified in RFC4447 [PWE3-CONTROL]. 844 7.3 Signaling Advertisement Processing 846 A PE should process a received [PWE3-CONTROL] advertisement with PW- 847 type of IP Layer2 transport for IPLS as follows, 848 - Verify the IPLS VPN membership by matching the VPN-Id 849 signaled in the AGI field or the PW-ID field with all the 850 VPN-Ids configured in the PE. Discard and release the PW 851 label if VPN-Id is not found. 852 - Program the Forwarding Information Base (FIB) such that when 853 a unicast IP packet is received from an AC with its 854 destination MAC address matching the advertised MAC address, 855 the packet is forwarded out over the tunnel to the 856 advertising PE with the advertised PW-label as the inner 857 label. 859 A PE should process a received [PWE3-CONTROL] advertisement with the 860 PW type of Ethernet for IPLS as follows, 861 - Verify the IPLS VPN membership by matching the VPN-Id 862 signaled in the AGI field or the PW-ID field with all the 863 VPN-Ids configured in the PE. Discard and release the PW 864 label if VPN-Id is not found. 865 - Add the PW-label to the send broadcast replication tree for 866 the VPN-Id. This enables sending a copy of a 867 multicast/broadcast IP Ethernet frame or ARP Ethernet frame 868 or Neighbor Discovery frames from the AC to this pseudowire. 870 Internet Draft draft-ietf-l2vpn-ipls-16.txt 872 8. IANA Considerations 874 Since this document is being published as historic record, no 875 requests for IANA code points are necessary. However, if in 876 future, interest to pursue this proposal arises, the following 877 requests for IANA codes would become necessary. 879 8.1. LDP Status messages 881 This document uses new LDP status code. IANA already maintains a 882 registry of name "STATUS CODE NAME SPACE" defined by [RFC 5036]. The 883 following value is suggested for assignment: 885 0x000000XX "MAC Address of CE is absent" 887 8.2. Interface Parameters 889 This document proposes a new Interface Parameters sub-TLV, to be 890 assigned from the 'Pseudowire Interface Parameters Sub-TLV type 891 Registry'. The following value is suggested for the Parameter ID: 893 0xXX "Stack capability" 895 IANA is also requested to set up a registry of "L2VPN PE stack 896 capabilities". This is a 16 bit field. Stack capability values 897 0x000X is specified in Section 7. of this document. The remaining 898 bitfield values (0x0002,..,0x8000) are to be assigned by IANA using 899 the "IETF Consensus" policy defined in [RFC 5226]. 901 L2VPN PE Stack Capabilities: 903 Bit (Value) Description 904 =============== ========================================== 905 Bit 0 (0x000X) - IPv6 stack capability 906 Bit 1 (0x000X) - Reserved 907 Bit 2 (0x000X) - Reserved 908 . 909 . 910 . 911 Bit 14 (0xX000) - Reserved 912 Bit 15 (0xX000) - Reserved 914 9.0 Forwarding 916 9.1 Non-IP or non-ARP traffic 918 In an IPLS VPN, a PE forwards only IP and ARP traffic. All other 919 frames are dropped silently. If the CEs must pass non-IP traffic to 920 each other, they must do so through IP tunnels that terminate at the 921 CEs themselves. 923 Internet Draft draft-ietf-l2vpn-ipls-16.txt 925 9.2 Unicast IP Traffic 927 In IPLS, IP traffic is forwarded from the AC to the PW based on the 928 destination MAC address of the layer 2 frame (and not based on the 929 IP Header). 931 The PE identifies the FIB associated with an IPLS instance based on 932 the AC or the PW label. When a frame is received from an AC, the PE 933 uses the destination MAC address as the lookup key. When a frame is 934 received from a PW, the PE uses the PW-Label as the lookup key. The 935 frame is dropped if the lookup fails. 937 For IPv6 support, the unicast IP ICMP frame of Neighbor Discovery 938 Protocol [RFC 4861] is bi-casted; one copy is submitted to the 939 control plane and other copy to the PW, based on the destination MAC 940 address. 942 9.3 Broadcasts and Multicast IP Traffic 944 When the destination MAC address is either a broadcast or multicast, 945 a copy of the frame is sent to the control plane for CE discovery 946 purposes (see section 5.1). It is important to note that stricter 947 rate-limiting criteria is applied to frames sent to the control 948 plane, in order to avoid overwhelming it under adverse conditions 949 such as Denial of Service attack. The service provider should also 950 provide a configurable limitation to prevent overflowing of the 951 learned source addresses in a given IPLS instance. Also, caution 952 must be used such that only link local multicasts and broadcast IP 953 packets are sent to control plane. 955 When a multicast/broadcast IP packet is received from an AC, the PE 956 replicates it onto the Send Multicast Replication Tree (See section 957 6.3). When a multicast/broadcast IP Ethernet frame is received from 958 a pseudowire, the PE forwards a copy of the frame to all the ACs 959 associated with the respective IPLS VPN instance. Note that 960 'multicast' PW uses Ethernet encapsulation and hence does not 961 require additional header manipulations. 963 9.4 ARP Traffic 965 When a broadcast ARP frame is received over the AC, a copy of the 966 frame is sent to the control plane for CE discovery purposes. The PE 967 replicates the frame onto the Send Multicast Replication Tree (see 968 section 6.3), which results into a copy to be delivered to all the 969 remote PEs on the 'multicast' PW and other local CEs through the 970 egress ACs. 972 When a broadcast Ethernet ARP frame is received over the 'multicast' 973 PW, a copy of the Ethernet ARP frame is sent to all the ACs 974 associated with the IPLS instance. 976 Internet Draft draft-ietf-l2vpn-ipls-16.txt 978 When a unicast Ethernet ARP frame is received over the AC, a copy of 979 the frame is sent to the control plane for CE discovery 980 purposes. The PE may optionally do MAC DA lookup in the forwarding 981 table and send the ARP frame to a specific egress interface (AC or 982 'multicast' PW to a remote PE) or replicate the frame onto the Send 983 Multicast Replication Tree (see section 6.3). 985 When a unicast ARP Ethernet frame is received over the 'multicast' 986 PW, PE may optionally do MAC DA lookup in the forwarding table and 987 forward it to the AC where the CE is located. If the CE is not 988 accessible through any local AC, the frame is dropped. Conversely, 989 the PE may simply forward the frame to all the ACs associated with 990 that IPLS instance without any lookup in the forwarding table. 992 9.5 Discovery of IPv6 CE devices 994 A PE device that supports IPv6 MUST be capable of, 996 - Intercepting ICMPv6 Neighbor Discovery [RFC 4861] packets 997 received over the AC. 998 - Record the IPv6 interface addresses and CE link-layer addresses 999 present in these packets 1000 - Forward them towards the original destination 1001 A PE device may also intercept Router Discovery packets in order to 1002 discover the link layer address and IPv6 interface address(es) of 1003 the CE. Following sections describe the details. 1005 The PE device MUST learn the link-layer address of the local CE and 1006 be able to use it when forwarding traffic between CEs. The PE MAY 1007 also wish to monitor the source link-layer address of data packets 1008 received from the CE, and discard packets not matching its learned 1009 CE link-layer address. The PE device may also optionally learn a 1010 list of CE IPv6 interface addresses for its directly-attached CE. 1012 9.5.1. Processing of Neighbor Solicitations 1014 When a broadcast Neighbor Solicitation frame is received over the 1015 AC, a copy of the frame is sent to the control plane for CE 1016 discovery purposes. The PE replicates the frame onto the Send 1017 Multicast Replication Tree (see section 6.3), which results in a 1018 copy to be delivered to all the remote PEs on the 'multicast' PW and 1019 other local CEs through the egress ACs. The PE may optionally learn 1020 an IPv6 interface address (If provided - this will not be the case 1021 for Duplicate Address Detection) when present. 1023 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1025 When a broadcast Ethernet Neighbor Solicitation frame is received 1026 over the 'multicast' PW, a copy is sent to all the ACs associated 1027 with the IPLS instance. 1029 9.5.2 Processing of Neighbor Advertisements 1031 When a unicast Neighbor Advertisement is received over the AC, a 1032 copy of the frame is sent to the control plane for the CE discovery 1033 purposes. The PE may optionally do MAC DA lookup in the forwarding 1034 table and send the Neighbor Advertisement frame to a specific egress 1035 interface (AC or 'multicast' PW to a remote PE) or replicate the 1036 frame onto the Send Multicast Replication Tree (see section 6.3). 1038 Optionally, PE could learn the IPv6 Interface address of the CE. 1040 When a unicast Neighbor Advertisement frame is received over the 1041 'multicast' PW, PE may optionally do MAC DA lookup in the forwarding 1042 table and forward it to the AC where the CE is located. If the CE is 1043 not accessible through any local AC, the frame is dropped. 1044 Conversely, the PE may simply forward the frame to all the ACs 1045 associated with that IPLS instance without any lookup in the 1046 forwarding table. 1048 9.5.3 Processing of Inverse Neighbor Solicitations and Advertisement 1050 Inverse Neighbor Discovery is typically used on non-broadcast links, 1051 but are allowed on broadcast links too [RFC 3122]. PE may optionally 1052 intercept Inverse Neighbor Solicitation and Advertisement and learn 1053 MAC and IPv6 interface address list of the attached CE from the copy 1054 of the frame sent to the control plane. The PE may optionally do MAC 1055 DA lookup in the forwarding table and send another copy of the frame 1056 to a specific egress interface (AC or 'multicast' PW to a remote PE) 1057 or replicate the frame onto the Send Multicast Replication Tree (see 1058 section 6.3). 1060 9.5.4 Processing of Router Solicitations and Advertisements 1062 Router Solicitations (RS) are multicast while Router Advertisement 1063 (RA) can be unicast or multicast Ethernet frames. The PE could 1064 optionally intercept RS and RA frames and send a copy to control 1065 plane. The PE may learn the MAC address and a list of interface 1066 addresses for the attached CE. 1068 For unicast RA, the PE may optionally do MAC DA lookup in the 1069 forwarding table and send the Neighbor Advertisement frame to a 1070 specific egress interface (AC or 'multicast' PW to a remote PE) or 1071 replicate the frame onto the Send Multicast Replication Tree (see 1072 section 6.3). The multicast RA and RS Ethernet frames are replicated 1073 using the Send Multicast Replication Tree as described in section 1074 6.3. 1076 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1078 9.6 Encapsulation 1080 The Ethernet MAC header of a unicast IP packet received from an AC 1081 is stripped before forwarding the frame to the unicast pseudowire. 1082 However, the MAC header is retained for the following cases, 1083 . when a frame is unicast or broadcast IP packet that is directed 1084 to one or more local AC(s). 1085 . when a frame is a broadcast IP packet 1086 . when a frame is an ARP packet 1087 . when a frame is Neighbor/Router Solicitation/Advertisement 1089 An IP frame received over a unicast pseudowire is prepended with a 1090 MAC header before transmitting it on the appropriate AC(s). The 1091 fields in the MAC header are filled in as follows: 1092 - The destination MAC address is the MAC address associated 1093 with the PW label in the FIB 1094 - The source MAC address is the PE's own local MAC address or a 1095 MAC address which has been specially configured on the PE for 1096 this use. 1097 - The Ethernet Type field is 0x0800 if IPv4 or 0x86DD if IPv6 1098 [RFC 2464] 1099 - The frame may be IEEE802.1Q tagged based on the VLAN 1100 information associated with the AC. 1102 An FCS is appended to the frame. 1104 10.0 Attaching to IPLS via ATM or FR 1106 In addition to (i) an Ethernet port and a (ii) combination of 1107 Ethernet port and a VLAN ID, an AC to IPLS may also be (iii) an ATM 1108 or FR VC carrying encapsulated bridged Ethernet frames or (iv) the 1109 combination of an ATM or FR VC and a VLAN ID. 1111 The ATM/FR VC is just used as a way to transport Ethernet frames 1112 between a customer site and the PE. The PE terminates the ATM/FR VC 1113 and operates on the encapsulated Ethernet frames exactly as if those 1114 were received on a local Ethernet interface. When a frame is 1115 propagated from pseudowire to a ATM or FR VC the PE prepends the 1116 Ethernet frame with the appropriate bridged encapsulation header as 1117 defined in [RFC 2684] and [RFC 2427] respectively. Operation of an 1118 IPLS over ATM/FR VC is exactly as described above, with the 1119 exception that the AC is then identified via the ATM VCI/VPI or 1120 Frame Relay DLCI (instead of via a local Ethernet port ID), or a 1121 combination of those with a VLAN ID. 1123 11.0 VPLS vs IPLS 1125 The VPLS approach proposed in [VPLS] provides VPN services for IP as 1126 well as other protocols. The IPLS approach described in this draft 1127 is similar to VPLS in many respects: 1129 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1131 - It provides a Provider Provisioned Virtual LAN service with 1132 multipoint capability where a CE connected via a single 1133 attachment circuit can reach many remote CEs 1134 - It appears as a broadcast domain and a single subnet 1135 - forwarding is based on destination MAC addresses 1137 However, unlike VPLS, IPLS is restricted to IP traffic only. By 1138 restricting the scope of the service to the predominant type of 1139 traffic in today's environment, IPLS eliminates the need for service 1140 provider edge routers to implement some bridging functions such as 1141 MAC address learning in the data path (by, instead, distributing MAC 1142 information in the control plane). Thus this solution offers a 1143 number of benefits: 1145 - Facilitates Virtual LAN services in instances where PE 1146 devices cannot or cannot efficiently (or are specifically 1147 configured not to) perform MAC address learning. 1148 - Unknown Unicast frames are never flooded as would be the case 1149 in VPLS. 1150 - Encapsulation is more efficient (MAC header is stripped) for 1151 unicast IP packets while traversing the backbone network. 1152 - PE devices are not burdened with the processing overhead 1153 associated with traditional bridging (e.g., STP processing, 1154 etc.). Note, however, that some of these overheads (e.g., STP 1155 processing) could optionally be turned-off with a VPLS 1156 solution in the case where it is known that only IP devices 1157 are interconnected. 1158 - Loops (perhaps through backdoor links) are minimized since a 1159 PE could easily reject (via label release) a duplicate IP to 1160 MAC address advertisement. 1161 - Greater control over CE topology distribution. 1163 12.0 IP Protocols 1165 The solution described in this document offers IPLS service for IPv4 1166 and IPv6 traffic only. For this reason, the MAC Header is not 1167 carried over the unicast pseudowire. It is reconstructed by the PE 1168 when receiving a packet from a unicast pseudowire and the Ethertype 1169 0x0800 or 0x86DD is used in the MAC Header since IPv4 or IPv6 1170 respectively, is assumed. 1172 However, this solution may be extended to carry other types of 1173 important traffic such as ISIS , which does not use Ethernet-II, 1174 EtherType based header. In order to permit the propagation of such 1175 packets correctly, one may create a separate set of pseudowires, or 1176 pass protocol information in the "control word" of a "multiprotocol" 1177 pseudowire, or encapsulate the Ethernet MAC Header in the 1178 pseudowire. The selection of appropriate multiplexing/demultiplexing 1179 schemes is the subject of future study. The current document focuses 1180 on IPLS service for IPv4 and IPv6 traffic. 1182 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1184 13.0 Dual Homing with IPLS 1186 As stated in previous sections, IPLS prohibits connection of a 1187 common LAN or VLAN to more than one PE. However, the CE device 1188 itself can connect to more than one instance of IPLS through two 1189 separate LAN or VLAN connections to separate PEs. To the CE IP 1190 device, these separate connections appear as connections to two IP 1191 subnets. The failure of reachability through one subnet is then 1192 resolved via the other subnet using IP routing protocols. 1194 14.0 Proxy ARP function 1196 The earlier version of this proposal used IP-PW to carry both the 1197 broadcast/multicast and unicast IP traffic. It also discussed how PE 1198 proxy functionality responds to the ARP requests of the local CE on 1199 behalf of remote CE. The current version of the draft eliminated 1200 these functions and instead uses Ethernet PW to carry broadcast, 1201 multicast and ARP frames to remote PEs. The motivation to use 1202 Ethernet PW and propagate ARP frames in the current version is to 1203 support configuration like back-to-back IPLS (similar to Inter 1204 AS option-A configurations in [RFC 4364]). 1206 The termination and controlled propagation of ARP frames is still a 1207 desirable option for security, DoS and other purposes. For these 1208 reasons, we re-introduce the ARP Proxy [PROXY-ARP] function in this 1209 revision as an optional feature. Following sections describe this 1210 option. 1212 14.1 ARP Proxy - Responder 1214 As a local configuration, a PE can enable ARP Proxy responder 1215 function. In this mode, local PE responds to ARP requests received 1216 over the Attachment Circuit via learnt IP and MAC address 1217 associations, which are advertised by the remote PEs. In addition, 1218 PE may utilize local policies to determine if ARP requests should be 1219 responded based on the source of the ARP request, rate at which the 1220 ARP requests are generated, etc. In a nutshell, when this feature is 1221 enabled, ARP requests are not propagated to remote PE routers that 1222 are members of the same IPLS instance. 1224 14.2 ARP Proxy - Generator 1226 As a local configuration, a PE can enable ARP Proxy generator 1227 function. In this mode, the PE generates ARP request for each IP and 1228 MAC address associations received from the remote PEs. The remote 1229 CE's IP and MAC address is used as the source information in the ARP 1230 request while the destination IP address in the request is obtained 1231 from the local configuration (that is, user needs to configure an IP 1232 address when this feature is enabled). The ARP request is sent on 1233 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1235 the Attachment Circuits that have ARP Proxy Generator enabled and is 1236 associated with the given IPLS instance. 1238 In addition, the PE may utilize local policies to determine which 1239 IP/MAC addresses are candidate for ARP request generation. 1241 The ARP Proxy Generator feature is required to support back-to-back 1242 IPLS configuration when any member of the IPLS instance is using ARP 1243 Proxy Responder function. An example of a back-to-back IPLS is a 1244 configuration where PE-1 (ASBR) in an IPLS cloud in one Autonomous 1245 System (say, AS-1) is connected via an Attachment Circuit to another 1246 PE-2 (ASBR) in an IPLS cloud in another Autonomous System (say, AS- 1247 2) where each PE appears as CE to each other. Such configuration is 1248 described in [RFC 4364] as option-A for inter-AS connectivity. The 1249 Proxy ARP responder feature prevents propagation of ARP requests to 1250 PE-1 (ASBR) in AS-1. This necessitates that PE-1 (ASBR) in AS-1 1251 generate ARP request on behalf of each CE connected to the IPLS 1252 instance in AS-1 as a mean to 'advertise' the reachability to IPLS 1253 cloud in AS-2 1255 15.0 Data Center Applicability 1257 The resurgence of interest in providing IP/MPLS based solution for 1258 Data Center Networks (DCN) deserves another look at the IPLS 1259 methodologies described in this document. The key requirement of 1260 DCN to permit VM mobility within or across DCN necessiates 1261 extending the reachability of IP subnet over a LAN, transparently. 1262 In addition, VMs tendency to generate frequent gratutious ARPs 1263 for location discovery necessiates a solution that curbs broadcasts 1264 closest to the source. 1266 The IPLS solution facilitates VM mobility by the PE closest to 1267 the new location signaling the MAC address to all remote peers. 1268 In addition, control-plane based MAC learning mechanisms prevent 1269 flooding of unknown unicast across DCN. The optional ARP proxy 1270 mechanisms further reduces ARP broadcast floods by preventing 1271 its reach across local PE. 1273 16.0 Acknowledgements 1275 Authors would like to thank Alp Dibirdi from Alcatel, Xiahou from 1276 Huawei and other L2VPN working group members for their valuable 1277 comments. 1279 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1281 17.0 Security Considerations 1283 A more comprehensive description of the security issues involved in 1284 L2VPNs are covered in [VPN-SEC]. Most of the security issues can be 1285 avoided through implementation of appropriate guards. The security 1286 aspect of this solution is addressed for two planes; control plane 1287 and data plane. 1289 17.1 Control plane security 1291 The control plane security pertains to establishing the LDP 1292 connection, pseudo-wire establishment and CE's IP and MAC address 1293 distribution. The LDP connection between two trusted PEs can be 1294 achieved by each PE verifying the incoming connection against the 1295 configured peer's address and authenticating the LDP messages by 1296 verifying keyed digests. The pseudo-wire establishments between two 1297 secure LDP peers do not pose security issue but mis-wiring could 1298 occur due to configuration error. Some checks, such as, proper 1299 pseudo-wire type and other pseudo-wire options may prevent mis- 1300 wiring due to configuration errors. 1302 The learning of the appropriate CE's IP and MAC address can be a 1303 security issue. It is expected that the local attachment circuit to 1304 CE be physically secured. If this is a concern, the PE must be 1305 configured with CE's IP and MAC address. During each ARP frame 1306 processing, PE must verify the received information against the 1307 configuration before accepting. This prevents theft of service, 1308 denial of service to a subscriber or DoS attacks to all subscribers 1309 by malicious use of network services. 1311 The IPLS also provides MAC anti spoofing by preventing the use of 1312 already known MAC address. For instance, if a PE has already learned 1313 a presence of a CE through local connection or from another PE, and 1314 subsequently an advertisement for the same MAC and/or IP address is 1315 received from a different PE, the receiving PE can terminate service 1316 to that CE (either through label release and/or removing the ARP 1317 entry from the FIB) and raise the alarm. 1319 The IPLS learns and distributes CE reachability through the control 1320 plane. This provides greater control over CE topology distribution 1321 through application of local policies. 1323 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1325 17.2 Data plane security 1327 The data traffic between CE and PE is not encrypted and it is 1328 possible that in an insecure environment, a malicious user may tap 1329 into the CE to PE connection and could conduct an active or passive 1330 attack. An example of an active attack would be generating traffic 1331 using the spoofed destination MAC address on the Ethernet Attachment 1332 Circuit and a passive attack could include targeted or passive 1333 monitoring between the CE and PE. In order to avoid such hijacking, 1334 local PE may verify the source MAC address of the received frame 1335 against the MAC address of the admitted connection. The frame is 1336 forwarded to PW only when authenticity is verified. When spoofing is 1337 detected, PE must severe the connection with the local CE, tear down 1338 the PW and start over. 1340 Each IPLS instance uses its own FIB. This prevents leaking of one 1341 customer data into another. 1343 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1345 18.0 References 1347 18.1 Normative References 1349 [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution 1350 Protocol". 1352 [PWE3-CONTROL] L. Martini et al., "Pseudowire Setup and Maintenance 1353 using LDP", RFC 4447. 1355 [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire 1356 Edge to Edge Emulation (PWE3)", RFC 4446. 1358 [PWE3-ETH] Martini et al., "Encapsulation Methods for Transport of 1359 Ethernet over MPLS Networks", RFC 4448. 1361 [VPLS] Lasserre et al, "Virtual Private LAN Service Using LDP", RFC 1362 4762, January 2007. 1364 [RFC 5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1365 "LDP Specification", RFC 5036, October 2007. 1367 [IEEE 802.1D] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993, "MAC 1368 Bridges". 1370 [RFC 4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1371 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1372 September 2007. 1374 [RFC 2464] Crawford, M., "Transmission of IPv6 packets over 1375 Ethernet Networks", RFC 2464, December 1998. 1377 [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 1378 Inverse Discovery Specification", RFC 3122, June 2001. 1380 [RFC 5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1381 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1382 May 2008. 1384 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1386 18.2 Informative References 1388 [L2VPN-FWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 1389 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1390 September 2006. 1392 [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". 1394 [L2VPN-REQTS] Augustyn, W. et.al "Service Requirements for Layer 2 1395 Provider Provisioned Virtual Private Networks", 1396 RFC 4665, September 2006. 1398 [L2VPN-SIG] Rosen et al., "Provisioning, Autodiscovery, and 1399 signaling in L2VPN", RFC 6074, Jan 2011. 1401 [RFC-1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1402 1112, August, 1989. 1404 [RFC 2684] Grossman, et al., "Multiprotocol Encapsulation over ATM 1405 Adaptation Layer 5", September 1999. 1407 [RFC 2427] Brown, et al., "Multiprotocol Interconnect over Frame 1408 Relay", September 1998. 1410 [RFC 4364] Rosen et al., "BGP/MPLS IP Virtual Private Network 1411 (VPNs)", February 2006. 1413 [VPN-SEC] Fang, L., "Security framework for Provider Provisioned 1414 Virtual Private Networks", RFC 4111, July 2005. 1416 [ADDR-IANA] http://www.iana.org/assignments/address-family-numbers/ 1417 address-family-numbers.xhtml 1419 Internet Draft draft-ietf-l2vpn-ipls-16.txt 1421 18.0 Author's Address 1423 Himanshu Shah 1424 Ciena Corp 1425 3939 North 1st Street, 1426 San Jose, CA 95110 1427 Email: hshah@ciena.com 1429 Eric Rosen 1430 Cisco Systems 1431 300 Apollo Drive, 1432 Chelmsford, MA 01824 1433 Email: erosen@cisco.com 1435 Giles Heron 1436 Cisco Systems 1437 Email: giheron@cisco.com 1439 Francois Le Faucheur 1440 Cisco Systems, Inc. 1441 Village d'Entreprise Green Side - Batiment T3 1442 400, Avenue de Roumanille 1443 06410 Biot-Sophia Antipolis, France 1444 Email: flefauch@cisco.com