idnits 2.17.1 draft-ietf-l2vpn-ipls-13.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [VPLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (ref. 'PWE3-CONTROL') (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Working Group Himanshu Shah 3 Intended Status: Historical Ciena Corp 4 Internet Draft 5 Eric Rosen 6 Francois Le Faucheur 7 Giles Heron 8 Cisco Systems 9 February 10, 2014 11 IP-Only LAN Service (IPLS) 12 draft-ietf-l2vpn-ipls-13.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 10, 2014 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 Internet Draft draft-ietf-l2vpn-ipls-13.txt 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect 57 systems across a wide-area or metropolitan-area network, making it 58 appear that they are on a private LAN. The systems which are 59 interconnected may themselves be LAN switches. If, however, they 60 are IP hosts or IP routers, certain simplifications to the operation 61 of the VPLS are possible. We call this simplified type of VPLS an 62 "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN 63 interfaces are run in promiscuous mode, and frames are forwarded 64 based on their destination MAC addresses. However, the maintenance 65 of the MAC forwarding tables is done via signaling, rather than via 66 the MAC address learning procedures specified in [IEEE 802.1D]. 67 This draft specifies the protocol extensions and procedures for 68 support of the IPLS service. 70 Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC 2119]. 76 Table of Contents 78 Copyright Notice .................................................... 1 79 Abstract.............................................................. 2 80 1.0 Contributing Authors ............................................. 3 81 2.0 Overview.......................................................... 4 82 2.1 Terminology ..................................................... 7 83 3.0 Topology.......................................................... 8 84 4.0 Configuration..................................................... 9 85 Internet Draft draft-ietf-l2vpn-ipls-13.txt 87 5.0 Discovery........................................................ 10 88 5.1 CE discovery ................................................... 10 89 5.1.1 IPv4 based CE discovery ..................................... 10 90 5.1.2 Ipv6 based CE discovery [RFC 4861] .......................... 10 91 6.0 Pseudowire Creation.............................................. 11 92 6.1 Receive Unicast Multipoint-to-point Pseudowire ................. 11 93 6.2 Receive Multicast Multipoint-to-point Pseudowire ............... 11 94 6.3 Send Multicast Replication tree ................................ 12 95 7.0 Signaling........................................................ 13 96 7.1 IPLS PW Signaling .............................................. 13 97 7.2 IPv6 Capability Advertisement .................................. 17 98 7.3 Signaling Advertisement Processing ............................. 18 99 8. IANA Considerations............................................... 19 100 8.1. LDP Status messages ........................................... 19 101 8.2. Interface Parameters .......................................... 19 102 9.0 Forwarding....................................................... 19 103 9.1 Non-IP or non-ARP traffic ...................................... 19 104 9.2 Unicast IP Traffic ............................................. 20 105 9.3 Broadcasts and Multicast IP Traffic ............................ 20 106 9.4 ARP Traffic .................................................... 20 107 9.6 Encapsulation .................................................. 23 108 10.0 Attaching to IPLS via ATM or FR............................... 23 109 11.0 VPLS vs IPLS.................................................... 23 110 12.0 IP Protocols.................................................... 24 111 13.0 Dual Homing with IPLS........................................... 25 112 14.0 Proxy ARP function.............................................. 25 113 14.1 ARP Proxy - Responder ......................................... 25 114 14.2 ARP Proxy - Generator ......................................... 25 115 15.0 Data Center Applicability ...................................... 25 116 16.0 Acknowledgements................................................ 26 117 17.0 Security Considerations......................................... 27 118 17.1 Control plane security ........................................ 27 119 17.2 Data plane security ........................................... 28 120 18.0 References...................................................... 29 121 18.1 Normative References .......................................... 29 122 18.2 Informative References ........................................ 29 123 19.0 Author's Address................................................ 30 125 1.0 Contributing Authors 126 Internet Draft draft-ietf-l2vpn-ipls-13.txt 128 This document is the combined effort of the following individuals 129 and many others who have carefully reviewed this document and 130 provided the technical clarifications. 132 K. Arvind Fortress 133 Vach Kompella/Mathew Bocci Alcatel/Lucent 134 Shane Amante Level3 136 2.0 Overview 138 As emphasized in [VPLS], Ethernet has become popular as an access 139 technology in Metropolitan and Wide Area Networks. [VPLS] describes 140 how geographically dispersed customer LANs can be interconnected 141 over a service provider's network. The VPLS service is provided by 142 Provider Edge (PE) devices that connect Customer Edge (CE) devices. 143 The VPLS architecture provides this service by incorporating 144 bridging functions such as MAC address learning in the PE devices. 146 Provider Edge platforms are designed primarily to be IP routers, 147 rather than to be LAN switches. To add VPLS capability to a PE 148 router, one has to add MAC address learning capabilities, along with 149 aging and other mechanisms native to Ethernet switches. This may be 150 fairly complex to add to the forwarding plane architecture of an IP 151 router. As discussed in [L2VPN-FWK], in scenarios where the CE 152 devices are NOT LAN switches, but rather are IP hosts or IP routers, 153 it is possible to provide the VPLS service without requiring MAC 154 address learning and aging on the PE. Instead, a PE router has to 155 have the capability to match the destination MAC address in a packet 156 received from a CE to an outbound pseudowire. The requirements for 157 the IPLS service are described in [L2VPN-REQTS]. The purpose of this 158 document is to specify a solution optimized for IPLS. 160 IPLS provides a VPLS-like service using PE routers that are not 161 designed to perform general LAN bridging functions. One must be 162 willing to accept the restriction that an IPLS be used for IP 163 traffic only, and not used to interconnect CE devices that are 164 themselves LAN switches. This is an acceptable restriction in many 165 environments, given that IP is the predominant type of traffic in 166 today's networks. 168 In IPLS, a PE device implements multi-point LAN connectivity for IP 169 traffic using the following key functions: 171 1. CE Address Discovery: Each Provider Edge (PE) device discovers 172 MAC address of the locally attached Customer Edge (CE) IP 173 devices, for each IPLS instance configured on the PE device. In 174 some configurations, PE also learns the IP address of the CE 175 device (when performing ARP proxy functions, described later in 176 the document). 178 Internet Draft draft-ietf-l2vpn-ipls-13.txt 180 2. Pseudowire (PW) for Unicast Traffic: For each locally attached 181 CE device in a given IPLS instance, a PE device sets up a 182 pseudowire (PW-LSP) to each of the other PEs that supports the 183 same IPLS instance. 185 For instance, if PEx and PEy both support IPLS I, and PEy is 186 locally attached to CEa and CEb, PEy will initiate the setup of 187 two pseudowires between itself and PEx. One of these will be 188 used to carry unicast traffic from any of PEx's CE devices to 189 CEa. The other will be used to carry unicast traffic from any 190 of PEx's CE devices to CEb. 192 Note that these pseudowires carry traffic only in one 193 direction. Further, while the pseudowire implicitly identifies 194 the destination CE of the traffic, it does not identify the 195 source CE; packets from different source CEs bound to the same 196 destination CE are sent on a single pseudowire. 198 3. Pseudowires for Multicast Traffic: In addition, every PE 199 supporting a given IPLS instance will set up a special 200 'multicast pseudowire' to every other PE in that IPLS instance. 201 If, in the above example, one of PEx's CE devices sends a 202 multicast packet, PEx would forward the multicast packet to PEy 203 on the special 'multicast' pseudowire. PEy would then send a 204 copy of that packet to CEa and a copy to CEb. 206 The 'multicast' pseudowire carries Ethernet frames of 207 multicast/broadcast IP, ARP and ICMP (Inverse) Neighbor 208 Discovery (ND/IND) packets for IPv6. Thus when a PE sends a 209 multicast packet across the network, it sends one copy to each 210 remote PE (supporting the given IPLS instance). If a 211 particular remote PE has more than one CE device in that IPLS 212 instance, the remote PE must replicate the packet and send one 213 copy to each of its local CEs. 215 As with the pseudowires that are used for unicast traffic, 216 packets travel in only one direction on these pseudowires, and 217 packets from different sources may be freely intermixed. 219 4. Signaling: The necessary pseudowires can be set up and 220 maintained using the LDP-based signaling procedures described 221 in [PWE3-CONTROL]. 223 A PE may assign the same label to each of the unicast 224 pseudowires that lead to a given CE device, in effect creating 225 a multipoint-to-point pseudowire. 227 Similarly, a PE may assign the same label to each of the 228 'multicast' pseudowires for a given IPLS instance, in effect 229 creating a multipoint-to-point pseudowire. 231 Internet Draft draft-ietf-l2vpn-ipls-13.txt 233 When setting up a pseudowire to be used for unicast traffic, 234 the PE must also signal the MAC address of the corresponding CE 235 device. It should also, optionally, advertise IP address of the 236 local CE device, especially when ARP proxy function is 237 configured or simply for operational management purposes. 238 Similarly, for IPv6 support, PE may optionally advertise the 239 IPv6 addresses of the local CE device. 241 5. ARP Packet Forwarding: ARP packets [ARP] are forwarded from 242 attachment circuit (AC) to 'multicast' pseudowires in the 243 Ethernet frame format as described by [PWE3-ETH]. Following 244 rules are observed when processing ARP packets, 245 a. Both broadcast (request) and unicast (response) ARP 246 packets are sent over the 'multicast' pseudowire. 247 b. When an ARP packet is received from an AC, the packet is 248 copied to control plane for learning MAC address of the 249 CE. Optionally, IP address is also learned to record the 250 association of IP and MAC address. 251 c. All Ethernet packets, including ARP packets, received from 252 'multicast' pseudowire are forwarded out to all the ACs 253 associated with the IPLS instance. These packets are not 254 copied to control plane. 256 6. ICMP IPv6 ND/IND related Packet Forwarding: (Inverse) Neighbor 257 Discovery (ND/IND) IPv6 packets from an AC are replicated and a 258 copy is sent to other ACs and to 'multicast' PWs associated 259 with the IPLS instance in the native Ethernet format, 260 unchanged. A copy is also submitted to Control Plane to learn 261 the MAC address and optionally corresponding IPv6 addresses. 263 7. Multicast IP packet forwarding: An IP Ethernet frame received 264 from an AC is replicated to other ACs and the 'multicast' 265 pseudowires associated with the IPLS instance. An IP Ethernet 266 frame received from a 'multicast' pseudowire is replicated to 267 all the egress ACs associated with the IPLS instance. 269 8. Unicast IP packet forwarding: An IP packet received from the AC 270 is forwarded based on the MAC DA lookup in the forwarding 271 table. If a match is found, the packet is forwarded to the 272 associated egress interface. If the egress interface is unicast 273 pseudowire, the packet is sent without MAC header. If the 274 egress interface is a local AC the Ethernet frame is forwarded 275 as such. An IP packet received from the unicast pseudowire is 276 forwarded to egress AC with MAC header prepended. The MAC DA is 277 derived from the forwarding table while MAC SA is the MAC 278 address of the PE. 280 Internet Draft draft-ietf-l2vpn-ipls-13.txt 282 Both VPLS [VPLS] and IPLS require the ingress PE to forward a frame 283 based on its destination MAC address. However, two key differences 284 between VPLS and IPLS can be noted from the above description: 286 . In VPLS, MAC entries are placed in the FIB of the ingress PE as 287 a result of MAC address learning (which occurs in the data 288 plane) while in IPLS MAC entries are placed in the FIB as a 289 result of pseudowire signaling operations (control plane). 290 . In VPLS, the egress PE looks up a frame's destination MAC 291 address to determine the egress AC; in IPLS, the egress AC is 292 determined entirely by the ingress PW-label. 294 The following sections describe the details of the IPLS scheme. 296 2.1 Terminology 298 IPLS IP-only LAN service (a type of Virtual Private 299 LAN Service that is restricted to IP traffic 300 only). 302 mp2p PW Multipoint-to-Point Pseudowire. A pseudowire 303 that carries traffic from remote PE devices to 304 a PE device that signals the pseudowire. The 305 signaling PE device advertises the same PW- 306 label to all remote PE devices that participate 307 in the IPLS service instance. In IPLS, for a 308 given IPLS instance, an mp2p PW used for IP 309 unicast traffic is established by a PE for each 310 CE device locally attached to that PE. It is a 311 unidirectional tree whose leaves consist of the 312 remote PE peers (which connect at least one AC 313 associated with the same IPLS instance) and 314 whose root is the signaling PE. Traffic flows 315 from the leaves towards the root. 317 Multicast PW Multicast/broadcast Pseudowire. A special kind 318 of mp2p PW that carries IP multicast/broadcast 319 traffic, all ARP frames and ICMP (I)ND frames 320 for IPv6. In the IPLS architecture, for each 321 IPLS instance supported by a PE, that PE device 322 establishes exactly one multicast PW. Multicast 323 PW uses Ethernet encapsulation. 325 Unicast PW Unicast Pseudowire carries IP unicast packets. 326 A PE creates unicast PW for each locally 327 attached CE. The unicast PW uses IP Layer2 328 transport encapsulation. 330 Internet Draft draft-ietf-l2vpn-ipls-13.txt 332 CE Customer Edge device. In this document, a CE is 333 any IP node (host or router) connected to the 334 IPLS LAN service. 336 Replication Tree The collection of all multicast PWs and ACs 337 that are members of an IPLS service instance on 338 a given PE. When a PE receives a 339 multicast/broadcast packet from an AC, the PE 340 device sends a copy of the packet to every 341 multicast pseudowire and AC of the replication 342 tree, excluding the AC on which the packet was 343 received. When a PE receives a packet from a 344 multicast PW, the PE device sends a copy of the 345 packet to all the ACs of the replication tree 346 and never to other PWs. 348 (I)ND (Inverse) Neighbor Discovery in IPv6 uses ICMP 349 packets. It is a protocol that uses Neighbor 350 solicitation/Advertisement PDUs. 352 RS Router Solicitation. Hosts generate all router 353 multicast ICMP packet to discover IPv6 router 354 on the local link. 356 RA Router Advertisement. Router generates all 357 multicast ICMP packet to advertise its presence 358 on the link. A unicast response is also sent 359 when RS is received. 361 NS Neighbor Solicitation in IPv6 uses (multicast) 362 ICMP packets to resolve IPv6 interface address 363 to MAC address association. 365 NA Neighbor Advertisement in IPv6 uses (unicast) 366 ICMP packets to respond to NS. 368 3.0 Topology 370 The Customer Edge (CE) devices are IP nodes (hosts or routers) that 371 are connected to PE devices either directly, or via an Ethernet 372 network. We assume that the PE/CE connection may be regarded by the 373 PE as an "interface" to which one or more CEs are attached. This 374 interface may be a physical LAN interface or a VLAN. The Provider 375 Edge (PE) routers are MPLS Label Edge Routers (LERs) that serve as 376 pseudowire endpoints. 378 Internet Draft draft-ietf-l2vpn-ipls-13.txt 380 +----+ +----+ 381 + S1 +---+ ........................... +---| S2 | 382 +----+ | | . . | +----+ 383 IPa | | +----+ +----+ | IPe 384 + +---| PE1|---MPLS and/or IP---| PE2|---+ 385 / \ +----+ |Network +----+ | 386 +----+ +---+ . | . | +----+ 387 + S1 + | S1| . +----+ . +---| S2 | 388 +----+ +---+ ..........| PE3|........... +----+ 389 IPb IPc +----+ IPf 390 | 391 | 392 +----+ 393 | S3 | 394 +----+ 395 IPd 397 In the above diagram, an IPLS instance is shown with three sites: 398 site S1, site S2 and site S3. In site S3, the CE device is directly 399 connected to its PE. In the other two sites, there are multiple CEs 400 connected to a single PE. More precisely, the CEs at these sites are 401 on an Ethernet (switched at site 1 and shared at site 2) network (or 402 VLAN), and the PE is attached to that same Ethernet network or 403 VLAN). We impose the following restriction: if one or more CEs 404 attach to a PE by virtue of being on a common LAN or VLAN, there 405 MUST NOT be more than one PE on that LAN or VLAN. 407 PE1, PE2 and PE3 are shown as connected via an MPLS network; 408 however, other tunneling technologies, such as GRE, L2TPv3, etc., 409 could also be used to carry the pseudowires. 411 An IPLS instance is a single broadcast domain, such that each IP end 412 station (e.g., IPa) appears to be co-located with other IP end 413 stations (e.g., IPb through IPf) on the same subnet. The IPLS 414 service is transparent to the CE devices and requires no changes to 415 them. 417 4.0 Configuration 419 Each PE router is configured with one or more IPLS service 420 instances, and each IPLS service instance is associated with a 421 unique VPN-Id. For a given IPLS service instance, a set of ACs is 422 identified. Each AC can be associated with only one IPLS instance. 423 An AC, in this document, is either a customer-facing Ethernet port, 424 or a particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a 425 customer-facing Ethernet port. 427 The PE router can optionally be configured with a local MAC address 428 to be used as source MAC address when IP packets are forwarded from 429 Internet Draft draft-ietf-l2vpn-ipls-13.txt 431 a pseudowire to an AC. By default, a PE uses the MAC address of the 432 customer-facing Ethernet interface for this purpose. 434 5.0 Discovery 436 The discovery process includes: 437 . Remote PE discovery 438 . VPN (i.e., IPLS) membership discovery 439 . IP CE end station discovery 441 This draft does not discuss the remote PE discovery or VPN 442 membership discovery. This information can either be user configured 443 or can be obtained using auto-discovery techniques described in 444 [L2VPN-SIG] or other methods. However, the discovery of the CE is an 445 important operational step in the IPLS model and is described below. 447 5.1 CE discovery 449 Each PE actively detects the presence of local CEs by snooping IP 450 and ARP frames received over the ACs. When an AC configured in an 451 IPLS instance becomes operational, it enters the CE discovery phase. 452 In this phase, the PE examines each multicast/broadcast Ethernet 453 frame. For link-local IP frames (for example IGP 454 discovery/multicast/broadcast packets typically 224.0.0.x addresses 455 [RFC-1112]), the CE's (source) MAC address is extracted from the 456 Ethernet header and the (source) IP address is obtained from the IP 457 header. 459 For each CE, the PE maintains the following tuple: . 463 5.1.1 IPv4 based CE discovery 465 As indicated earlier, a copy of ARP frames received over the AC is 466 submitted to the control plane. The PE learns MAC address and 467 optionally IP address of the CE from the source address fields of 468 the ARP PDU. 470 Once a CE is discovered, its status is monitored continuously by 471 examining the received ARP frames and by periodically generating ARP 472 requests. The absence of an ARP response from a CE after a 473 configurable number of ARP requests is interpreted as loss of 474 connectivity with the CE. 476 5.1.2 Ipv6 based CE discovery [RFC 4861] 478 A copy of Neighbor and Router Discovery frames received over the AC 479 are submitted to the control plane in the PE. 481 Internet Draft draft-ietf-l2vpn-ipls-13.txt 483 If the PE receives a Neighbor Solicitation message, and the source 484 IP address of the message is not the unspecified address, the PE 485 learns the MAC address and optionally IP address of the CE. 487 If the PE receives an unsolicited Neighbor Advertisement message, 488 the PE learns the source MAC address and optionally the IP address 489 of the CE. 491 If the PE receives a Router Solicitation, and the source IP address 492 of the message is not the unspecified address, the PE learns source 493 MAC address and optionally the IP address of the CE. 495 If the PE receives a Router Advertisement, it learns source MAC 496 address and optionally the IP address of the CE. 498 The PE will periodically generate Neighbor Solicitation messages for 499 the IP address of the CE as a means of verifying the continued 500 existence of the address and its MAC address binding. The absence of 501 a response from the CE device for a given number of retries could be 502 interpreted as a loss of connectivity with the CE. 504 6.0 Pseudowire Creation 506 6.1 Receive Unicast Multipoint-to-point Pseudowire 508 As the PE discovers each locally attached CE, a unicast multipoint- 509 to-point pseudowire (mp2p PW) associated exclusively with that CE is 510 created by distributing the MAC address and optionally IP address of 511 the CE along with a PW-Label to all the remote PE peers that 512 participate in the same IPLS instance. Note that the same value of a 513 PW-label SHOULD be distributed to all the remote PE peers for a 514 given CE. The mp2p PW thus created is used by remote PEs to send 515 unicast IP traffic to a specific CE. 517 (The same functionality can be provided by a set of point-to-point 518 PWs, and the PE is not required to send the same PW-label to all the 519 other PEs. For convenience, however, we will use the term mp2p PWs, 520 which may be implemented using a set of point-to-point PWs.) 522 The PE forwards a frame received over this mp2p PW to the associated 523 AC. 525 The unicast pseudowire uses IP Layer2 Transport encapsulation as 526 define in [PWE3-CONTROL]. 528 6.2 Receive Multicast Multipoint-to-point Pseudowire 530 When a PE is configured to participate in an IPLS instance, it 531 advertises a 'multicast' PW-label to every other PE that is a member 532 Internet Draft draft-ietf-l2vpn-ipls-13.txt 534 of the same IPLS. The advertised PW-label value is the same for each 535 PE, which creates an mp2p pseudowire. There is only one such 536 multicast mp2p PW per PE for each IPLS instance and this pseudowire 537 is used exclusively to carry IP multicast/broadcast, ARP traffic and 538 (inverse) Neighbor Discovery packets for IPv6 from the remote PEs to 539 this PE for this IPLS instance. 541 Note that no special functionality is expected from this pseudowire. 542 We call it a 'multicast' pseudowire because we use it to carry 543 multicast and broadcast IP, ARP and IPv6 Neighbor Discovery traffic. 544 The pseudowire itself need not provide any different service than 545 any of the unicast pseudowires. 547 In particular, the Receive multicast mp2p PW does not perform any 548 replication of frames itself. Rather, it is there to signify to the 549 PE that the PE may need to replicate a copy of a frame received over 550 this mp2p PW onto all the AC that are associated with the IPLS 551 instance of the mp2p PW. 553 The multicast mp2p pseudowire is considered the principle pseudowire 554 in the bundle of mp2p pseudowires that consist of one multicast mp2p 555 pseudowire and a variable number of unicast mp2p pseudowires for a 556 given IPLS instance. In a principle role, multicast PW represents 557 the IPLS instance. The life of all unicast PWs in the IPLS instance 558 depends on the existence of the multicast PW. If, for some reasons, 559 multicast PW cease to exist, all the associated unicast pseudowires 560 in the bundle are removed. 562 The multicast pseudowire uses Ethernet encapsulation as defined in 563 [PWE3-ETH]. 565 The use of pseudowires which are specially optimized for multicast 566 is for further study. 568 6.3 Send Multicast Replication tree 570 The PE creates a send replication tree for each IPLS instance, which 571 consists of the collection of all ACs and all the 'multicast' 572 pseudowires of the IPLS instance. 574 Any ARP, Neighbor Discovery or multicast IP Ethernet frame received 575 over an AC is replicated to the other ACs and to the mp2p multicast 576 pseudowire of the send replication tree. The send replication tree 577 deals mostly with broadcast/multicast Ethernet MAC frames. One 578 exception to this is unicast ARP and IPv6 Neighbor Discovery frame, 579 the processing of which is described in the following section. 581 Any Ethernet frame received over the multicast PW is replicated to 582 all the ACs of the send replication tree of the IPLS instance 583 associated with the incoming PW label. One exception is unicast ARP 584 Internet Draft draft-ietf-l2vpn-ipls-13.txt 586 and Neighbor Discovery frame used for IPv6, the processing of which 587 is described in the following section. 589 7.0 Signaling 591 [PWE3-CONTROL] uses the Label Distribution Protocol (LDP) to 592 exchange PW-FECs in the Label Mapping message in a downstream 593 unsolicited mode. The PW-FEC comes in two forms; PWid and 594 Generalized PWid FEC elements. These FEC elements define some fields 595 that are common between them. The discussions below refer to these 596 common fields for IPLS related extensions. Note that the use of 597 multipoint to point and unidirectional characteristics of the PW 598 makes BGP as the ideal candidate for PW-FEC signaling. The use of 599 BGP for such purposes is for future study. 601 7.1 IPLS PW Signaling 603 An IPLS carries IP packets as payload over its unicast pseudowires 604 and Ethernet packet as payload over its multicast pseudowire. The 605 PW-type to be used for unicast pseudowire is the IP PW, defined in 606 [PWE3-CONTROL] as IP Layer2 Transport. The PW-type to be used for 607 multicast pseudowire is the Ethernet PW as defined in [PWE3-ETH]. 608 The PW-Type values for these encapsulations are defined in [PWE3- 609 IANA]. 611 When processing a received PW FEC, the PE matches the PW Id with the 612 locally configured PW Id for the IPLS instance. If the PW type is 613 Ethernet, the PW-FEC is for multicast PW. If the PW type is 'IP 614 Layer2 transport', the PW FEC is for unicast PW. 616 For unicast PW, PE must check the presence of MAC address TLV in the 617 optional parameter fields of the Label Mapping message. If this 618 parameter is absent, a Label Release message must be issued with a 619 Status Code meaning "MAC Address of the CE is absent" [note: Status 620 Code 0x0000004C is pending IANA allocation], to reject the 621 establishment of the unicast PW with the remote PE. 623 The PE may optionally include IP address TLV based on the user 624 configuration for advertising of the IP addresses of the local CE. 626 The processing of the address list TLV is as follows. 628 o If a pseudowire is configured for AC with IPv4 CEs only, the 629 PE should advertise address list tlv with address family type 630 to be of IPv4 address. The PE should process the IPv4 address 631 list TLV as described in this document. 632 o If a pseudowire is configured for AC with both IPv4 and IPv6 633 CEs, the PE should advertise IPv6 capability using the 634 procedures described in Section below. 636 Internet Draft draft-ietf-l2vpn-ipls-13.txt 638 o If a PE does not receive any IP address list TLV or IPv6 639 capability advertisement, it MAY assume IPv4 behavior. 641 The IPLS uses the Address List TLV as defined in [RFC 5036] to 642 signal the MAC (and optionally IP) address of the local CE. There 643 are two TLVs defined below; IP Address TLV and MAC Address TLV. MAC 644 address TLV must be included in the optional parameter field of the 645 Label Mapping message when establishing the unicast IP PW for IPLS. 647 When configured to support specific type of IP traffic (IPv4 or 648 IPv6), the PE augments verification of the type of traffic PW will 649 carry using the Address Family Type value. If there is a mismatch 650 between the received Address Family value and the expectation of 651 IPLS instance to which the PW belongs, the PE must issue a Label 652 Release message with a Status Code meaning "IP Address type 653 mismatch" (Status Code 0x0000004A) to reject the PW establishment. 655 Encoding of the IP Address TLV is: 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 |0|0| Address List (0x0101) | Length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Address Family | CE's IP Address | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | CE's IP Address | | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Length 668 When Address Family is IPV4, Length is equal to 6 bytes; 669 2 bytes for address family and 4 bytes of IP address. 671 Address Family 672 Two octet quantity containing a value from the ADDRESS FAMILY 673 NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232] that encodes 674 the addresses contained in the Addresses field. 676 IP Address of the CE 677 IP address of the CE attached to the advertising PE. The 678 encoding of the individual address depends on the Address 679 Family. 681 The following address encodings are defined by this version of the 682 protocol: 684 Address Family Address Encoding 686 IPv4 (1) 4 octet full IPv4 address 688 Internet Draft draft-ietf-l2vpn-ipls-13.txt 690 IPv6 (2) 16 octet full IPv6 address 692 Note that more than one instance of the IP address TLV may exist, 693 especially when support for IPv6 is configured. 695 Internet Draft draft-ietf-l2vpn-ipls-13.txt 697 Encoding of the MAC Address TLV is: 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 |0|0| Address List (0x0101) | Length | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Address Family | CE's MAC address | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Length 710 The length field is set to value 8 (2 for address family, 6 for 711 MAC address) 713 Address Family 714 Two octet quantity containing a value from ADDRESS FAMILY 715 NUMBERS in [RFC 3232] that encodes the addresses contained in 716 the Addresses field. 718 CE's MAC Address 719 MAC address of the CE attached to the advertising PE. The 720 encoding of the individual address depends on the Address 721 Family. 723 The following address encodings are defined by this version of the 724 protocol: 726 Address Family Address Encoding 728 MAC (6) 6 octet full Ethernet MAC address 730 The IPv4 address of the CE is also supplied in the optional 731 parameters field of the LDP Notification message along with the PW 732 FEC. The LDP Notification message is used to signal any change in 733 the status of the CE's IPv4 address. 735 Note that Notification message does not apply to MAC address TLV 736 since an update to MAC address of the CE should result in label 737 withdraw followed by establishment of new PW with new MAC address of 738 the CE. However, advertisement of IP address(es) of the CE is 739 optional and changes may become known after the establishment of 740 unicast PW. 742 Internet Draft draft-ietf-l2vpn-ipls-13.txt 744 The encoding of the LDP Notification message is as follows. 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |0| Notification (0x0001) | Message Length | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Message ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Status (TLV) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | IP Address List TLV (as defined above) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | PWId FEC or Generalized ID FEC | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 The Status TLV status code is set to 0x0000002C "IP address of CE", 761 to indicate that IP Address update follows. Since this notification 762 does not refer to any particular message the Message Id, and Message 763 Type fields are set to 0. 765 The PW FEC TLV SHOULD NOT include the interface parameters as they 766 are ignored in the context of this message. 768 7.2 IPv6 Capability Advertisement 770 A 'Stack Capability' Interface Parameter sub-TLV is signaled by the 771 two PEs so that they can agree which stack(s) they should be using. 772 It is assumed by default that the IP PW will always be capable of 773 carrying IPv4 packets. Thus this capability sub-TLV is used to 774 indicate if other stacks need to be supported concurrently with 775 IPv4. 777 The 'Stack Capability' sub-TLV is part of the interface parameters 778 of the PW FEC. The proposed format for the Stack Capability 779 interface parameter sub-TLV is as follows: 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Parameter ID | Length | Stack Capability | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Parameter ID = 0x16 789 Length = 4 791 Stack capability = 0x0001 to indicate IPv6 stack capability 792 Internet Draft draft-ietf-l2vpn-ipls-13.txt 794 The Value of Stack capability is dependent on the PW type context. 795 For IP PW type, a setting of 0x0001 indicates IPv6 stack capability. 797 A PE that supports IPv6 on an IP PW MUST signal the stack capability 798 sub-TLV in the initial label mapping message for the PW. The PE 799 nodes compare the value advertised by the remote PE with the local 800 configuration and only use a capability which is advertised by both. 801 If a PE that supports IPv6 does not receive a 'stack capability' 802 sub-TLV from the far-end PE in the initial label mapping message, or 803 one is received but it is set to a reserved value, the PE MUST send 804 an unsolicited release for the PW label with the LDP status code 805 meaning "IP Address type mismatch" (Status Code 0x0000004A). 807 The behavior of a PE that does not understand an interface parameter 808 sub-TLV is specified in RFC4447 [PWE3-CONTROL]. 810 7.3 Signaling Advertisement Processing 812 A PE should process a received [PWE3-CONTROL] advertisement with PW- 813 type of IP Layer2 transport for IPLS as follows, 814 - Verify the IPLS VPN membership by matching the VPN-Id 815 signaled in the AGI field or the PW-ID field with all the 816 VPN-Ids configured in the PE. Discard and release the PW 817 label if VPN-Id is not found. 818 - Program the Forwarding Information Base (FIB) such that when 819 a unicast IP packet is received from an AC with its 820 destination MAC address matching the advertised MAC address, 821 the packet is forwarded out over the tunnel to the 822 advertising PE with the advertised PW-label as the inner 823 label. 825 A PE should process a received [PWE3-CONTROL] advertisement with the 826 PW type of Ethernet for IPLS as follows, 827 - Verify the IPLS VPN membership by matching the VPN-Id 828 signaled in the AGI field or the PW-ID field with all the 829 VPN-Ids configured in the PE. Discard and release the PW 830 label if VPN-Id is not found. 831 - Add the PW-label to the send broadcast replication tree for 832 the VPN-Id. This enables sending a copy of a 833 multicast/broadcast IP Ethernet frame or ARP Ethernet frame 834 or Neighbor Discovery frames from the AC to this pseudowire. 836 Internet Draft draft-ietf-l2vpn-ipls-13.txt 838 8. IANA Considerations 840 8.1. LDP Status messages 842 This document uses new LDP status code. IANA already maintains a 843 registry of name "STATUS CODE NAME SPACE" defined by [RFC 5036]. The 844 following value is suggested for assignment: 846 0x0000004C "MAC Address of CE is absent" 848 8.2. Interface Parameters 850 This document proposes a new Interface Parameters sub-TLV, to be 851 assigned from the 'Pseudowire Interface Parameters Sub-TLV type 852 Registry'. The following value is suggested for the Parameter ID: 854 0x16 "Stack capability" 856 IANA is also requested to set up a registry of "L2VPN PE stack 857 capabilities". This is a 16 bit field. Stack capability values 858 0x0001 is specified in Section 7. of this document. The remaining 859 bitfield values (0x0002,..,0x8000) are to be assigned by IANA using 860 the "IETF Consensus" policy defined in [RFC 5226]. 862 L2VPN PE Stack Capabilities: 864 Bit (Value) Description 865 =============== ========================================== 866 Bit 0 (0x0001) - IPv6 stack capability 867 Bit 1 (0x0002) - Reserved 868 Bit 2 (0x0004) - Reserved 869 . 870 . 871 . 873 Bit 14 (0x4000) - Reserved 874 Bit 15 (0x8000) - Reserved 876 9.0 Forwarding 878 9.1 Non-IP or non-ARP traffic 880 In an IPLS VPN, a PE forwards only IP and ARP traffic. All other 881 frames are dropped silently. If the CEs must pass non-IP traffic to 882 each other, they must do so through IP tunnels that terminate at the 883 CEs themselves. 885 Internet Draft draft-ietf-l2vpn-ipls-13.txt 887 9.2 Unicast IP Traffic 889 In IPLS, IP traffic is forwarded from the AC to the PW based on the 890 destination MAC address of the layer 2 frame (and not based on the 891 IP Header). 893 The PE identifies the FIB associated with an IPLS instance based on 894 the AC or the PW label. When a frame is received from an AC, the PE 895 uses the destination MAC address as the lookup key. When a frame is 896 received from a PW, the PE uses the PW-Label as the lookup key. The 897 frame is dropped if the lookup fails. 899 For IPv6 support, the unicast IP ICMP frame of Neighbor Discovery 900 Protocol [RFC 4861] is bi-casted; one copy is submitted to the 901 control plane and other copy to the PW, based on the destination MAC 902 address. 904 9.3 Broadcasts and Multicast IP Traffic 906 When the destination MAC address is either a broadcast or multicast, 907 a copy of the frame is sent to the control plane for CE discovery 908 purposes (see section 5.1). It is important to note that the frames 909 sent to the control plane is applied stricter rate limiting criteria 910 to avoid overwhelming the control plane under adverse conditions 911 such as Denial Of Service attack. The service provider should also 912 provide a configurable limitation to prevent overflowing of the 913 learned source addresses in a given IPLS instance. Also, a caution 914 must be used such that only link local multicasts and broadcast IP 915 packets are sent to control plane. 917 When a multicast/broadcast IP packet is received from an AC, the PE 918 replicates it onto the Send Multicast Replication Tree (See section 919 6.3). When a multicast/broadcast IP Ethernet frame is received from 920 a pseudowire, the PE forwards a copy of the frame to all the ACs 921 associated with the respective IPLS VPN instance. Note that 922 'multicast' PW uses Ethernet encapsulation and hence does not 923 require additional header manipulations. 925 9.4 ARP Traffic 927 When a broadcast ARP frame is received over the AC, a copy of the 928 frame is sent to the control plane for CE discovery purposes. The PE 929 replicates the frame onto the Send Multicast Replication Tree (see 930 section 6.3), which results into a copy to be delivered to all the 931 remote PEs on the 'multicast' PW and other local CEs through the 932 egress ACs. 934 When a broadcast Ethernet ARP frame is received over the 'multicast' 935 PW, a copy of the Ethernet ARP frame is sent to all the ACs 936 associated with the IPLS instance. 938 Internet Draft draft-ietf-l2vpn-ipls-13.txt 940 When a unicast Ethernet ARP frame is received over the AC, a copy of 941 the frame is sent to the control plane for the CE discovery 942 purposes. The PE may optionally do MAC DA lookup in the forwarding 943 table and send the ARP frame to a specific egress interface (AC or 944 'multicast' PW to a remote PE) or replicate the frame onto the Send 945 Multicast Replication Tree (see section 6.3). 947 When a unicast ARP Ethernet frame is received over the 'multicast' 948 PW, PE may optionally do MAC DA lookup in the forwarding table and 949 forward it to the AC where the CE is located. If the CE is not 950 accessible through any local AC, the frame is dropped. Conversely, 951 the PE may simply forward the frame to all the ACs associated with 952 that IPLS instance without any lookup in the forwarding table. 954 9.5 Discovery of IPv6 CE devices 956 A PE device that supports IPv6 MUST be capable of, 958 - Intercepting ICMPv6 Neighbor Discovery [RFC 4861] packets 959 received over the AC. 960 - Record the IPv6 interface addresses and CE link-layer addresses 961 present in these packets 962 - Forward them towards the original destination 963 A PE device may also intercept Router Discovery packets in order to 964 discover the link layer address and IPv6 interface address(es) of 965 the CE. Following sections describe the details. 967 The PE device MUST learn the link-layer address of the local CE and 968 be able to use it when forwarding traffic between CEs. The PE MAY 969 also wish to monitor the source link-layer address of data packets 970 received from the CE, and discard packets not matching its learned 971 CE link-layer address. The PE device may also optionally learn a 972 list of CE IPv6 interface addresses for its directly-attached CE. 974 9.5.1. Processing of Neighbor Solicitations 976 When a broadcast Neighbor Solicitation frame is received over the 977 AC, a copy of the frame is sent to the control plane for CE 978 discovery purposes. The PE replicates the frame onto the Send 979 Multicast Replication Tree (see section 6.3), which results into a 980 copy to be delivered to all the remote PEs on the 'multicast' PW and 981 other local CEs through the egress ACs. The PE may optionally learn 982 an IPv6 interface address (If provided - this will not be the case 983 for Duplicate Address Detection) when present. 985 Internet Draft draft-ietf-l2vpn-ipls-13.txt 987 When a broadcast Ethernet Neighbor Solicitation frame is received 988 over the 'multicast' PW, a copy is sent to all the ACs associated 989 with the IPLS instance. 991 9.5.2 Processing of Neighbor Advertisements 993 When a unicast Neighbor Advertisement is received over the AC, a 994 copy of the frame is sent to the control plane for the CE discovery 995 purposes. The PE may optionally do MAC DA lookup in the forwarding 996 table and send the Neighbor Advertisement frame to a specific egress 997 interface (AC or 'multicast' PW to a remote PE) or replicate the 998 frame onto the Send Multicast Replication Tree (see section 6.3). 1000 Optionally, PE could learn the IPv6 Interface address of the CE. 1002 When a unicast Neighbor Advertisement frame is received over the 1003 'multicast' PW, PE may optionally do MAC DA lookup in the forwarding 1004 table and forward it to the AC where the CE is located. If the CE is 1005 not accessible through any local AC, the frame is dropped. 1006 Conversely, the PE may simply forward the frame to all the ACs 1007 associated with that IPLS instance without any lookup in the 1008 forwarding table. 1010 9.5.3 Processing of Inverse Neighbor Solicitations and Advertisement 1012 Inverse Neighbor Discovery is typically used on non-broadcast links, 1013 but are allowed on broadcast links too [RFC 3122]. PE may optionally 1014 intercept Inverse Neighbor Solicitation and Advertisement and learn 1015 MAC and IPv6 interface address list of the attached CE from the copy 1016 of the frame sent to the control plane. The PE may optionally do MAC 1017 DA lookup in the forwarding table and send another copy of the frame 1018 to a specific egress interface (AC or 'multicast' PW to a remote PE) 1019 or replicate the frame onto the Send Multicast Replication Tree (see 1020 section 6.3). 1022 9.5.4 Processing of Router Solicitations and Advertisements 1024 Router Solicitations (RS) are multicast while Router Advertisement 1025 (RA) can be unicast or multicast Ethernet frames. The PE could 1026 optionally intercept RS and RA frames and send a copy to control 1027 plane. The PE may learn the MAC address and a list of interface 1028 addresses for the attached CE. 1030 For unicast RA, the PE may optionally do MAC DA lookup in the 1031 forwarding table and send the Neighbor Advertisement frame to a 1032 specific egress interface (AC or 'multicast' PW to a remote PE) or 1033 replicate the frame onto the Send Multicast Replication Tree (see 1034 section 6.3). The multicast RA and RS Ethernet frames are replicated 1035 to using the Send Multicast Replication Tree as described in section 1036 6.3. 1038 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1040 9.6 Encapsulation 1042 The Ethernet MAC header of a unicast IP packet received from an AC 1043 is stripped before forwarding the frame to the unicast pseudowire. 1044 However, the MAC header is retained for the following cases, 1045 . when a frame is unicast or broadcast IP packet that is directed 1046 to one or more local AC(s). 1047 . when a frame is a broadcast IP packet 1048 . when a frame is an ARP packet 1049 . when a frame is Neighbor/Router Solicitation/Advertisement 1051 An IP frame received over a unicast pseudowire is prepended with a 1052 MAC header before transmitting it on the appropriate ACs). The 1053 fields in the MAC header are filled in as follows: 1054 - The destination MAC address is the MAC address associated 1055 with the PW label in the FIB 1056 - The source MAC address is the PE's own local MAC address or a 1057 MAC address which has been specially configured on the PE for 1058 this use. 1059 - The Ethernet Type field is 0x0800 if IPv4 or 0x86DD if IPv6 1060 [RFC 2464] 1061 - The frame may be IEEE802.1Q tagged based on the VLAN 1062 information associated with the AC. 1064 An FCS is appended to the frame. 1066 10.0 Attaching to IPLS via ATM or FR 1068 In addition to (i) an Ethernet port and a (ii) combination of 1069 Ethernet port and a VLAN ID, an AC to IPLS may also be (iii) an ATM 1070 or FR VC carrying encapsulated bridged Ethernet frames or (iv) the 1071 combination of an ATM or FR VC and a VLAN ID. 1073 The ATM/FR VC is just used as a way to transport Ethernet frames 1074 between a customer site and the PE. The PE terminates the ATM/FR VC 1075 and operates on the encapsulated Ethernet frames exactly as if those 1076 were received on a local Ethernet interface. When a frame is 1077 propagated from pseudowire to a ATM or FR VC the PE prepends the 1078 Ethernet frame with the appropriate bridged encapsulation header as 1079 defined in [RFC 2684] and [RFC 2427] respectively. Operation of an 1080 IPLS over ATM/FR VC is exactly as described above, with the 1081 exception that the AC is then identified via the ATM VCI/VPI or 1082 Frame Relay DLCI (instead of via a local Ethernet port ID), or a 1083 combination of those with a VLAN ID. 1085 11.0 VPLS vs IPLS 1087 The VPLS approach proposed in [VPLS] provides VPN services for IP as 1088 well as other protocols. The IPLS approach described in this draft 1089 is similar to VPLS in many respects: 1091 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1093 - It provides a Provider Provisioned Virtual LAN service with 1094 multipoint capability where a CE connected via a single 1095 attachment circuit can reach many remote CEs 1096 - It appears as a broadcast domain and a single subnet 1097 - forwarding is based on destination MAC addresses 1099 However, unlike VPLS, IPLS is restricted to IP traffic only. By 1100 restricting the scope of the service to the predominant type of 1101 traffic in today's environment, IPLS eliminates the need for service 1102 provider edge routers to implement some bridging functions such as 1103 MAC address learning in the data path (by, instead, distributing MAC 1104 information in the control plane). Thus this solution offers a 1105 number of benefits: 1107 - Facilitates Virtual LAN services in instances where PE 1108 devices cannot or cannot efficiently (or are specifically 1109 configured not to) perform MAC address learning. 1110 - Unknown Unicast frames are never flooded as would be the case 1111 in VPLS. 1112 - Encapsulation is more efficient (MAC header is stripped) for 1113 unicast IP packets while traversing the backbone network. 1114 - PE devices are not burdened with the processing overhead 1115 associated with traditional bridging (e.g., STP processing, 1116 etc.). Note however that some of these overheads (e.g., STP 1117 processing) could optionally be turned-off with a VPLS 1118 solution in the case where it is known that only IP devices 1119 are interconnected. 1120 - Loops (perhaps through backdoor links) are minimized since a 1121 PE could easily reject (via label release) a duplicate IP to 1122 MAC address advertisement. 1123 - Greater control over CE topology distribution. 1125 12.0 IP Protocols 1127 The solution described in this document offers IPLS service for IPv4 1128 and IPv6 traffic only. For this reason, the MAC Header is not 1129 carried over the unicast pseudowire. It is reconstructed by the PE 1130 when receiving a packet from a unicast pseudowire and the Ethertype 1131 0x0800 or 0x86DD is used in the MAC Header since IPv4 or IPv6 1132 respectively, is assumed. 1134 However, this solution may be extended to carry other types of 1135 important traffic such as ISIS , which does not use Ethernet-II, 1136 EtherType based header. In order to permit the propagation of such 1137 packets correctly, one may create a separate set of pseudowires, or 1138 pass protocol information in the "control word" of a "multiprotocol" 1139 pseudowire, or encapsulate the Ethernet MAC Header in the 1140 pseudowire. The selection of appropriate multiplexing/demultiplexing 1141 scheme is the subject of future study. The current document focuses 1142 on IPLS service for IPv4 and IPv6 traffic. 1144 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1146 13.0 Dual Homing with IPLS 1148 As stated in previous sections, IPLS prohibits connection of a 1149 common LAN or VLAN to more than one PE. However, the CE device 1150 itself can connect to more than one instance of IPLS through two 1151 separate LAN or VLAN connections to separate PEs. To the CE IP 1152 device, these separate connections appear as connections to two IP 1153 subnets. The failure of reachability through one subnet is then 1154 resolved via the other subnet using IP routing protocols. 1156 14.0 Proxy ARP function 1158 The earlier version of this proposal used IP-PW to carry both the 1159 broadcast/multicast and unicast IP traffic. It also discussed how PE 1160 proxy functionality responds to the ARP requests of the local CE on 1161 behalf of remote CE. The current version of the draft eliminated 1162 these functions and instead uses Ethernet PW to carry broadcast, 1163 multicast and ARP frames to remote PEs. The motivation to use 1164 Ethernet PW and propagate ARP frames in the current version is to 1165 support configuration like back-to-back IPLS (similar to Inter 1166 AS option-A configurations in [RFC 4364]). 1168 The termination and controlled propagation of ARP frames is still a 1169 desirable option for security, DoS and other purposes. For these 1170 reasons, we re-introduce the ARP Proxy [PROXY-ARP] function in this 1171 revision as an optional feature. Following sections describe this 1172 option. 1174 14.1 ARP Proxy - Responder 1176 As a local configuration, a PE can enable ARP Proxy responder 1177 function. In this mode, local PE responds to ARP requests received 1178 over the Attachment Circuit via learnt IP and MAC address 1179 associations, which are advertised by the remote PEs. In addition, 1180 PE may utilize local policies to determine if ARP requests should be 1181 responded based on the source of the ARP request, rate at which the 1182 ARP requests are generated, etc. In nutshell, when this feature is 1183 enabled, ARP requests are not propagated to remote PE routers that 1184 are members of the same IPLS instance. 1186 14.2 ARP Proxy - Generator 1188 As a local configuration, a PE can enable ARP Proxy generator 1189 function. In this mode, the PE generates ARP request for each IP and 1190 MAC address associations received from the remote PEs. The remote 1191 CE's IP and MAC address is used as the source information in the ARP 1192 request while the destination IP address in the request is obtained 1193 from the local configuration (that is, user needs to configure an IP 1194 address when this feature is enabled). The ARP request is sent on 1195 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1197 the Attachment Circuits that have ARP Proxy Generator enabled and is 1198 associated with the given IPLS instance. 1200 In addition, the PE may utilize local policies to determine which 1201 IP/MAC addresses are candidate for ARP request generation. 1203 The ARP Proxy Generator feature is required to support back-to-back 1204 IPLS configuration when any member of the IPLS instance is using ARP 1205 Proxy Responder function. An example of a back-to-back IPLS is a 1206 configuration where PE-1 (ASBR) in an IPLS cloud in one Autonomous 1207 System (say, AS-1) is connected via an Attachment Circuit to another 1208 PE-2 (ASBR) in an IPLS cloud in another Autonomous System (say, AS- 1209 2) where each PE appears as CE to each other. Such configuration is 1210 described in [RFC 4364] as option-A for inter-AS connectivity. The 1211 Proxy ARP responder feature prevents propagation of ARP requests to 1212 PE-1 (ASBR) in AS-1. This necessitates that PE-1 (ASBR) in AS-1 1213 generate ARP request on behalf of each CE connected to the IPLS 1214 instance in AS-1 as a mean to 'advertise' the reachability to IPLS 1215 cloud in AS-2 1217 15.0 Data Center Applicability 1219 The resurgence of interest in providing IP/MPLS based solution for 1220 Data Center Networks (DCN) deserves another look at the IPLS 1221 methodologies described in this document. The key requirement of 1222 DCN to permit VM mobility within or across DCN necessiates 1223 extending the reachability of IP subnet over a LAN, transparently. 1224 In addition, VMs tendancy to generate frequent gratutious ARPs 1225 for location discovery necessiates a solution that curbs broadcasts 1226 closest to the source. 1228 The IPLS solution facilitates VM mobility by way of PE closest to 1229 the new location signaling the MAC address to all remote peers. 1230 In addition, control-plane based MAC learning mechanisms prevent 1231 flooding of unknown unicast across DCN. The optional ARP proxy 1232 mechanisms further reduces ARP broadcast floods by preventing 1233 its reach across local PE. 1235 16.0 Acknowledgements 1237 Authors would like to thank Alp Dibirdi from Alcatel, Xiahou from 1238 Huawei and other L2VPN working group members for their valuable 1239 comments. 1241 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1243 17.0 Security Considerations 1245 A more comprehensive description of the security issues involved in 1246 L2VPNs are covered in [VPN-SEC]. Most of the security issues can be 1247 avoided through implementation of appropriate guards. The security 1248 aspect of this solution is addressed for two planes; control plane 1249 and data plane. 1251 17.1 Control plane security 1253 The control plane security pertains to establishing the LDP 1254 connection, pseudo-wire establishment and CE's IP and MAC address 1255 distribution. The LDP connection between two trusted PEs can be 1256 achieved by each PE verifying the incoming connection against the 1257 configured peer's address and authenticating the LDP messages using 1258 MD5 authentication. The pseudo-wire establishments between two 1259 secure LDP peers do not pose security issue but mis-wiring could 1260 occur due to configuration error. Some checks, such as, proper 1261 pseudo-wire type and other pseudo-wire options may prevent mis- 1262 wiring due to configuration errors. 1264 The learning of the appropriate CE's IP and MAC address can be a 1265 security issue. It is expected that the local attachment circuit to 1266 CE be physically secured. If this is a concern, the PE must be 1267 configured with CE's IP and MAC address. During each ARP frame 1268 processing, PE must verify the received information against the 1269 configuration before accepting. This prevents theft of service, 1270 denial of service to a subscriber or DoS attacks to all subscribers 1271 by malicious use of network services. 1273 The IPLS also provides MAC anti spoofing by preventing the use of 1274 already known MAC address. For instance, if a PE has already learned 1275 a presence of a CE through local connection or from another PE, and 1276 subsequently an advertisement for the same MAC and/or IP address is 1277 received from a different PE, the receiving PE can terminate service 1278 to that CE (either through label release and/or removing the ARP 1279 entry from the FIB) and raise the alarm. 1281 The IPLS learns and distributes CE reachability through the control 1282 plane. This provides greater control over CE topology distribution 1283 through application of local policies. 1285 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1287 17.2 Data plane security 1289 The data traffic between CE and PE is not encrypted and it is 1290 possible that in an insecure environment, a malicious user may tap 1291 into the CE to PE connection and generate traffic using the spoofed 1292 destination MAC address on the Ethernet Attachment Circuit. In 1293 order to avoid such hijacking, local PE may verify the source MAC 1294 address of the received frame against the MAC address of the 1295 admitted connection. The frame is forwarded to PW only when 1296 authenticity is verified. When spoofing is detected, PE must severe 1297 the connection with the local CE, tear down the PW and start over. 1299 Each IPLS instance uses its own FIB. This prevents leaking of one 1300 customer data into another. 1302 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1304 18.0 References 1306 18.1 Normative References 1308 [ARP] RFC 826, STD 37, D. Plummer, "An Ethernet Address Resolution 1309 Protocol". 1311 [PWE3-CONTROL] L. Martini et al., "Pseudowire Setup and Maintenance 1312 using LDP", RFC 4447. 1314 [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire 1315 Edge to Edge Emulation (PWE3)", RFC 4446. 1317 [PWE3-ETH] Martini et al., "Encapsulation Methods for Transport of 1318 Ethernet over MPLS Networks", RFC 4448. 1320 [VPLS] Lasserre et al, "Virtual Private LAN Service Using LDP", RFC 1321 4762, January 2007. 1323 [RFC 5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1324 "LDP Specification", RFC 5036, October 2007. 1326 [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate 1327 requirement levels". 1329 [IEEE 802.1D] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993, "MAC 1330 Bridges". 1332 [RFC 4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1333 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1334 September 2007. 1336 [RFC 2464] Crawford, M., "Transmission of IPv6 packets over 1337 Ethernet Networks", RFC 2464, December 1998. 1339 [RFC 3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 1340 Inverse Discovery Specification", RFC 3122, June 2001. 1342 [RFC 5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1343 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1344 May 2008. 1346 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1348 18.2 Informative References 1350 [L2VPN-FWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 1351 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1352 September 2006. 1354 [PROXY-ARP] RFC 925, J. Postel, "Multi-LAN Address Resolution". 1356 [L2VPN-REQTS] Augustyn, W. et.al "Service Requirements for Layer 2 1357 Provider Provisioned Virtual Private Networks", 1358 RFC 4665, September 2006. 1360 [L2VPN-SIG] Rosen et al., "Provisioning, Autodiscovery, and 1361 signaling in L2VPN", RFC 6074, Jan 2011. 1363 [RFC-1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1364 1112, August, 1989. 1366 [RFC 2684] Grossman, et al., "Multiprotocol Encapsulation over ATM 1367 Adaptation Layer 5", September 1999. 1369 [RFC 2427] Brown, et al., "Multiprotocol Interconnect over Frame 1370 Relay", September 1998. 1372 [RFC 4364] Rosen et al., "BGP/MPLS IP Virtual Private Network 1373 (VPNs)", February 2006. 1375 [VPN-SEC] Fang, L., "Security framework for Provider Provisioned 1376 Virtual Private Networks", RFC 4111, July 2005. 1378 [RFC 3232] Reynolds and Postel, "Assigned Numbers". 1380 Internet Draft draft-ietf-l2vpn-ipls-13.txt 1382 18.0 Author's Address 1384 Himanshu Shah 1385 Ciena Corp 1386 3939 North 1st Street, 1387 San Jose, CA 95110 1388 Email: hshah@ciena.com 1390 Eric Rosen 1391 Cisco Systems 1392 300 Apollo Drive, 1393 Chelmsford, MA 01824 1394 Email: erosen@cisco.com 1396 Giles Heron 1397 Cisco Systems 1398 Email: giheron@cisco.com 1400 Francois Le Faucheur 1401 Cisco Systems, Inc. 1402 Village d'Entreprise Green Side - Batiment T3 1403 400, Avenue de Roumanille 1404 06410 Biot-Sophia Antipolis, France 1405 Email: flefauch@cisco.com