idnits 2.17.1 draft-ietf-l2vpn-arp-mediation-19.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 ([RFC4664]), 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 -- 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 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 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(Ciena) 3 Intended Status: Proposed Standard Eric Rosen(Cisco) 4 Internet Draft Giles Heron(Cisco) 5 Expires: July 10, 2012 Vach Kompella(Alcatel-Lucent) 7 January 10 2012 9 ARP Mediation for IP Interworking of Layer 2 VPN 10 draft-ietf-l2vpn-arp-mediation-19.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 10, 2012 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described 48 in Section 4.e of the Trust Legal Provisions and are provided 49 without warranty as described in the Simplified BSD License. 51 Abstract 53 The Virtual Private Wire Service (VPWS) [RFC4664] provides 54 point-to-point connections between pairs of Customer Edge (CE) 55 devices. It does so by binding two Attachment Circuits (each 56 connecting a CE device with a Provider Edge, PE, device) to a 57 pseudowire (connecting the two PEs). In general, the Attachment 58 Circuits must be of the same technology (e.g., both Ethernet, 59 both ATM), and the pseudowire must carry the frames of that 60 technology. However, if it is known that the frames' payload 61 consists solely of IP datagrams, it is possible to provide a 62 point-to-point connection in which the pseudowire connects 63 Attachment Circuits of different technologies. This requires the 64 PEs to perform a function known as "ARP Mediation". ARP 65 Mediation refers to the process of resolving Layer 2 addresses 66 when different resolution protocols are used on either 67 Attachment Circuit. The methods described in this document are 68 applicable even when the CEs run a routing protocol between 69 them, as long as the routing protocol runs over IP. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 74 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described 76 in [RFC2119]. 78 Table of Contents 80 Copyright Notice........................................... 1 81 1. Introduction............................................... 4 82 2. ARP Mediation (AM) function................................ 6 83 3. IP Layer 2 Interworking Circuit............................ 7 84 4. IP Address Discovery Mechanisms............................ 7 85 4.1. Discovery of IP Addresses of Locally Attached IPv4 CE. 8 86 4.1.1. Monitoring Local Traffic......................... 8 87 4.1.2. CE Devices Using ARP............................. 8 88 4.1.3. CE Devices Using Inverse ARP.................... 10 89 4.1.4. CE Devices Using PPP............................ 10 90 4.1.5. Router Discovery method......................... 11 91 4.1.6. Manual Configuration............................ 12 92 4.2. How a CE Learns the IPv4 address of a remote CE...... 12 93 4.2.1. CE Devices Using ARP............................ 12 94 4.2.2. CE Devices Using Inverse ARP.................... 13 95 4.2.3. CE Devices Using PPP............................ 13 96 4.3. Discovery of IP Addresses of IPv6 CE Devices......... 13 97 4.3.1. Distinguishing Factors Between IPv4 and IPv6.... 13 98 4.3.2. Requirements for PEs............................ 14 99 4.3.3. Processing of Neighbor Solicitations............ 15 100 4.3.4. Processing of Neighbor Advertisements........... 15 101 4.3.5. Processing Inverse Neighbor Solicitations (INS). 16 102 4.3.6. Processing of Inverse Neighbor Advertisements .. 17 103 4.3.7. Processing of Router Solicitations.............. 18 104 4.3.8. Processing of Router Advertisements............. 18 105 4.3.9. Duplicate Address Detection..................... 18 106 4.3.10. CE address discovery for CEs attached using PPP 19 107 5. CE IPv4 Address Signaling between PEs..................... 19 108 5.1. When to Signal an IPv4 address of a CE............... 19 109 5.2. LDP Based Distribution of CE IPv4 Addresses.......... 20 110 6. IPv6 Capability Advertisement............................. 22 111 6.1. PW Operational Down on Stack Capability Mis-Match.... 23 112 6.2. Stack Capability Fall-back........................... 24 113 7. IANA Considerations....................................... 25 114 7.1. LDP Status messages.................................. 25 115 7.2. Interface Parameters................................. 25 116 8. Security Considerations................................... 26 117 8.1. Control Plane Security............................... 26 118 8.2. Data plane security.................................. 27 119 9. Acknowledgements.......................................... 27 120 10. References............................................... 27 121 10.1. Normative References................................ 27 122 10.2. Informative References.............................. 29 123 11. Authors' Addresses....................................... 29 124 APPENDIX A:.................................................. 32 125 A.1. Use of IGPs with IP L2 Interworking L2VPNs........... 32 126 A.1.1. OSPF............................................ 32 127 A.1.2. RIP............................................. 33 128 A.1.3. IS-IS........................................... 33 130 1. Introduction 132 Layer 2 Virtual Private Networks (L2VPN) are constructed over a 133 Service Provider IP/MPLS backbone but are presented to the 134 Customer Edge (CE) devices as Layer 2 networks. In theory, 135 L2VPNs can carry any Layer 3 protocol, but in many cases, the 136 Layer 3 protocol is IP. Thus it makes sense to consider 137 procedures that are optimized for IP. 139 In a typical implementation, illustrated in the diagram below, 140 the CE devices are connected to the Provider Edge (PE) devices 141 via Attachment Circuits (AC). The ACs are Layer 2 circuits. In 142 a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via 143 AC2, both ACs would have to be of the same type (i.e., both 144 Ethernet, both Frame Relay, etc.). However, if it is known that 145 only IP traffic will be carried, the ACs can be of different 146 technologies, provided that the PEs provide the appropriate 147 procedures to allow the proper transfer of IP packets. 149 +-----+ 150 +------ -----| CE3 | 151 |AC3 +-----+ 152 +-----+ 153 ......| PE3 |........... 154 . +-----+ . 155 . | . 156 . | . 157 +-----+ AC1 +-----+ Service +-----+ AC2 +-----+ 158 | CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 | 159 +-----+ +-----+ Backbone +-----+ +-----+ 160 . . 161 ........................ 163 A CE, which is connected via a given type of AC, may use an IP 164 Address Resolution procedure that is specific to that type of 165 AC. For example, an Ethernet-attached IPv4 CE would use ARP 166 [RFC826] and a Frame Relay-attached CE might use Inverse ARP 167 [RFC2390]. If we are to allow the two CEs to have a Layer 2 168 connection between them, even though each AC uses a different 169 Layer 2 technology, the PEs must intercept and "mediate" the 170 Layer 2 specific address resolution procedures. 172 In this document, we specify the procedures for VPWS services, 173 which the PEs MUST implement in order to mediate the IP address 174 resolution mechanism. We call these procedures "ARP Mediation". 175 Consider a Virtual Private Wire Service (VPWS) constructed 176 between CE1 and CE2 in the diagram above. If AC1 and AC2 are of 177 different technologies, e.g. AC1 is Ethernet and AC2 is Frame 178 Relay (FR), then ARP requests coming from CE1 cannot be passed 179 transparently to CE2. PE1 MUST interpret the meaning of the ARP 180 requests and mediate the necessary information with PE2 before 181 responding. 183 The document uses "ARP" terminology to mean any protocol that is 184 used to resolve IP addresses to link layer addresses. For 185 instance in IPv4, ARP and Inverse ARP protocols are used for 186 address resolution while in IPv6 Neighbor Discovery [RFC4861] 187 and Inverse Neighbor Discovery protocol [RFC3122] based on 188 ICMPv6 are used for address resolution. 190 2. ARP Mediation (AM) function 192 The ARP Mediation (AM) function is an element of a PE node that 193 deals with the IP address resolution for CE devices connected 194 via a VPWS L2VPN. By placing this function in the PE node, ARP 195 Mediation is transparent to the CE devices. 197 For a given point-to-point connection between a pair of CEs, the 198 ARP Mediation procedure depends on whether the packets being 199 forwarded are IPv4 or IPV6. A PE that is to perform ARP 200 Mediation for IPv4 packets MUST perform the following logical 201 steps: 203 1. Discover the IP address of the locally attached CE device 204 2. Terminate, do not forward ARP and Inverse ARP requests 205 from the CE device at the local PE. 206 3. Distribute the IP Address to the remote PE using 207 pseudowire control signaling. 208 4. Notify the locally attached CE of the IP address of the 209 remote CE. 210 5. Respond appropriately to ARP and Inverse ARP requests from 211 the local CE device, using IP address of the remote CE and 212 the hardware address of the local PE. 214 A PE that is to perform ARP Mediation for IPv6 packets SHOULD 215 perform the following logical steps: 217 1. Discover the IPv6 addresses of the locally attached CE device, 218 together with those of the remote CE device. 219 2. 220 a. Intercept Neighbor Discovery (ND) and Inverse Neighbor 221 Discovery (IND) packets received from the local CE 222 device. 223 b. From these NB and IND packets learn the IPv6 224 configuration of the CE. 226 c. Forward the ND and IND packets over the pseudowire to the 227 remote PE. 228 3. Intercept Neighbor Discovery and Inverse Neighbor Discovery 229 packets received over the pseudowire from the remote PE, 230 possibly modifying them (if required for the type of outgoing 231 AC) before forwarding to the local CE, and also learning 232 information about the IPv6 configuration of the remote CE. 233 Details for the above-described procedures are given in the 234 following sections. 236 3. IP Layer 2 Interworking Circuit 238 The IP Layer 2 interworking Circuit refers to interconnection of 239 the Attachment Circuit with the IP Layer 2 Transport pseudowire 240 that carries IP datagrams as the payload. The ingress PE removes 241 the data link header of its local Attachment Circuit and 242 transmits the payload (an IP packet) over the pseudowire with or 243 without the optional control word. If the IP packet arrives at 244 the ingress PE with multiple data link headers (for example in 245 the case of bridged Ethernet PDU on an ATM Attachment Circuit), 246 all data link headers MUST be removed from the IP packet before 247 transmission over the PW. The egress PE encapsulates the IP 248 packet with the data link header used on its local Attachment 249 Circuit. 251 The encapsulation for the IP Layer 2 Transport pseudowire is 252 described in [RFC4447]. The "IP Layer 2 interworking circuit" 253 pseudowire is also referred to as "IP pseudowire" in this 254 document. 256 In the case of an IPv6 L2 Interworking Circuit, the egress PE 257 MAY modify the contents of Neighbor Discovery or Inverse 258 Neighbor Discovery packets before encapsulating the IP packet 259 with the data link header. 261 4. IP Address Discovery Mechanisms 263 An IP Layer 2 Interworking Circuit enters monitoring state 264 immediately after configuration. During this state it performs 265 two functions. 267 - Discovery of the CE IP device(s) 268 - Establishment of the PW 270 The establishment of the PW occurs independently from local CE 271 IP address discovery. During the period when the PW has been 272 established but the local CE IP device has not been discovered, 273 only broadcast/multicast IP frames are propagated between the 274 Attachment Circuit and pseudowire; unicast IP datagrams are 275 dropped. The IP destination address is used to classify 276 unicast/multicast packets. 278 Unicast IP frames are propagated between the AC and pseudowire 279 only when CE IP devices on both Attachment Circuits have been 280 discovered, notified and proxy functions have completed. 282 The need to wait for address resolution completion before 283 unicast IP traffic can flow is simple. 285 . PEs do not perform routing operations 286 . The destination IP address in the packet is not necessarily 287 that of the attached CE 288 . On a broadcast link, there is no way to find out the MAC 289 address of the CE based on the Destination IP address of 290 the packet. 292 4.1. Discovery of IP Addresses of Locally Attached IPv4 CE 294 A PE MUST support manual configuration of IPv4 CE addresses. 295 This section also describes automated mechanisms by which a PE 296 MAY also discover an IPv4 CE address. 298 4.1.1. Monitoring Local Traffic 300 The PE devices MAY learn the IP addresses of the locally 301 attached CEs from any IP traffic, such as link local multicast 302 packets (e.g., destined to 224.0.0.x), and are not restricted to 303 the operations below. 305 4.1.2. CE Devices Using ARP 306 If a CE device uses ARP to determine the IP address to MAC 307 address binding of its neighbor, the PE processes the ARP 308 requests to learn the IP address of the local CE for the local 309 Attachment Circuit. 311 This document mandates that there MUST be only one CE per 312 Attachment Circuit. However, customer facing access topologies 313 may exist whereby more than one CE appears to be connected to 314 the PE on a single Attachment Circuit. For example, this could 315 be the case when CEs are connected to a shared LAN that connects 316 to the PE. In such case, the PE MUST select one local CE. The 317 selection could be based on manual configuration or the PE MAY 318 optionally use the following selection criteria. In either case, 319 manual configuration of the IP address of the local CE (and its 320 MAC address) MUST be supported. 322 o Wait to learn the IP address of the remote CE (through PW 323 signaling) and then select the local CE that is sending 324 the request for IP address of the remote CE. 325 o Augment cross checking with the local IP address learned 326 through listening for link local multicast packets (as per 327 section 4.1.1. above). 328 o Augment cross checking with the local IP address learned 329 through the Router Discovery protocol (as described below 330 in section 4.1.5. ). 331 o There is still a possibility that the local PE may not 332 receive an IP address advertisement from the remote PE and 333 there may exist multiple local IP routers that attempt to 334 'connect' to remote CEs. In this situation, the local PE 335 MAY use some other criteria to select one IP device from 336 many (such as "the first ARP received"), or an operator 337 MAY configure the IP address of the local CE. Note that 338 the operator does not have to configure the IP address of 339 the remote CE (as that would be learned through pseudowire 340 signaling). 342 Once the local and remote CEs have been discovered for the given 343 Attachment Circuit, the local PE responds with its own MAC 344 address to any subsequent ARP requests from the local CE with a 345 destination IP address matching the IP address of the remote CE. 347 The local PE signals the IP address of the local CE to the 348 remote PE and MAY initiate an unsolicited ARP response to notify 349 the IP address to MAC address binding for the remote CE to the 350 local CE (again using its own MAC address). 352 Once the ARP mediation function is completed (i.e. the PE device 353 knows both the local and remote CE IP addresses), unicast IP 354 frames are propagated between the AC and the established PW. 356 The PE MAY periodically generate ARP request messages for the IP 357 address of the CE as a means of verifying the continued 358 existence of the IP address and its MAC address binding. The 359 absence of a response from the CE device for a given number of 360 retries could be used as a trigger for withdrawal of the IP 361 address advertisement to the remote PE. The local PE would then 362 re-enter the address resolution phase to rediscover the IP 363 address of the attached CE. Note that this "heartbeat" scheme is 364 needed only where the failure of a CE device may otherwise be 365 undetectable. 367 4.1.3. CE Devices Using Inverse ARP 369 If a CE device uses Inverse ARP to determine the IP address of 370 its neighbor, the attached PE processes the Inverse ARP request 371 from the Attachment Circuit and responds with an Inverse ARP 372 reply containing the IP address of the remote CE, if the address 373 is known. If the PE does not yet have the IP address of the 374 remote CE, it does not respond, but records the IP address of 375 the local CE and the circuit information. Subsequently, when the 376 IP address of the remote CE becomes available, the PE MAY 377 initiate an Inverse ARP request as a means of notifying the IP 378 address of the remote CE to the local CE. 380 This is the typical mode of operation for Frame Relay and ATM 381 Attachment Circuits. If the CE does not use Inverse ARP, the PE 382 can still discover the IP address of the local CE using the 383 mechanisms described in section 4.1.1. and 4.1.5. 385 4.1.4. CE Devices Using PPP 387 The IP Control Protocol [RFC1332] describes a procedure to 388 establish and configure IP on a point-to-point connection, 389 including the negotiation of IP addresses. When such an 390 Attachment Circuit is configured for IP interworking, PPP 391 negotiation is not performed end-to-end between CE devices. 392 Instead, PPP negotiation takes place between the CE and its 393 local PE. The PE performs proxy PPP negotiation and informs the 394 attached CE of the IP address of the remote CE during IPCP 395 negotiation using the IP-Address option (0x03). 397 When a PPP link completes LCP negotiations, the local PE MAY 398 perform the following IPCP actions: 400 o The PE learns the IP address of the local CE from the 401 Configure-Request received with the IP-Address option 402 (0x03). If the IP address is non-zero, the PE records the 403 address and responds with Configure-Ack. However, if the 404 IP address is zero, the PE responds with Configure-Reject 405 (as this is a request from the CE to assign it an IP 406 address). Also, the IP address option is set with zero 407 value in the Configure-Reject response to instruct the CE 408 not to include that option in any subsequent Configure- 409 Request. 410 o If the PE receives a Configure-Request without the IP- 411 Address option, it responds with a Configure-Ack. In this 412 case the PE is unable to learn the IP address of the local 413 CE using IPCP and hence MUST rely on other means as 414 described in sections 4.1.1. and 4.1.5. Note that in 415 order to employ other learning mechanisms, the IPCP 416 negotiations MUST have reached the open state. 417 o If the PE does not know the IP address of the remote CE, 418 it sends a Configure-Request without the IP-Address 419 option. 420 o If the PE knows the IP address of the remote CE, it sends 421 a Configure-Request with the IP-Address option containing 422 the IP address of the remote CE. 424 The IPCP IP-Address option MAY be negotiated between the PE and 425 the local CE device. Configuration of other IPCP options MAY be 426 rejected. Other NCPs, with the exception of the Compression 427 Control Protocol (CCP) and Encryption Control Protocol (ECP), 428 MUST be rejected. The PE device MAY reject configuration of the 429 CCP and ECP. 431 4.1.5. Router Discovery method 433 In order to learn the IP address of the CE device for a given 434 Attachment Circuit, the PE device MAY execute Router Discovery 435 Protocol [RFC1256] whereby a Router Discovery Request (ICMP - 436 router solicitation) message is sent using a source IP address 437 of zero. The IP address of the CE device is extracted from the 438 Router Discovery Response (ICMP - router advertisement) message 439 from the CE. It is possible that the response contains more than 440 one router addresses with the same preference level; in which 441 case, some heuristics (such as first on the list) are necessary. 442 The use of the Router Discovery method by the PE is optional. 444 4.1.6. Manual Configuration 446 In some cases, it may not be possible to discover the IP address 447 of the local CE device using the mechanisms described in 448 sections 4.1 - 4.1.5 above. In such cases manual configuration 449 MAY be used. All implementations of this document MUST support 450 manual configuration of the IPv4 address of the local CE. This 451 is the only REQUIRED mode for a PE to support. 453 The support for configuration of the IP address of the remote CE 454 is OPTIONAL. 456 4.2. How a CE Learns the IPv4 address of a remote CE 458 Once the local PE has received the IP address information of the 459 remote CE from the remote PE, it will either initiate an address 460 resolution request or respond to an outstanding request from the 461 attached CE device. 463 In the event that IPv4 address of the remote CE is manually 464 configured, the address resolution can begin immediately as 465 receipt of remote IP address of the CE becomes unnecessary. 467 4.2.1. CE Devices Using ARP 469 When the PE learns the IP address of the remote CE as described 470 in section 5.1 below, it may or may not already know the IP 471 address of the local CE. If the IP address is not known, the PE 472 MUST wait until it is acquired through one of the methods 473 described in sections 4.1.1, 4.1.2 and 4.1.5. If the IP address 474 of the local CE is known, the PE MAY choose to generate an 475 unsolicited ARP message to notify the local CE about the binding 476 of the IP address of the remote CE with the PE's own MAC 477 address. 479 When the local CE generates an ARP request, the PE MUST proxy 480 the ARP response [RFC925] using its own MAC address as the 481 source hardware address and the IP address of the remote CE as 482 the source protocol address. The PE MUST respond only to those 483 ARP requests whose destination protocol address matches the IP 484 address of the remote CE. 486 4.2.2. CE Devices Using Inverse ARP 488 When the PE learns the IP address of the remote CE, it SHOULD 489 generate an Inverse ARP request. If the Attachment Circuit 490 requires activation (e.g. Frame Relay) the PE SHOULD activate it 491 first before the Inverse ARP request. It should be noted, that 492 the PE might never receive the response to its own request, nor 493 see any Inverse ARP request from the CE, in cases where the CE 494 is pre-configured with the IP address of the remote CE or where 495 the use of Inverse ARP has not been enabled. In either case the 496 CE has used other means to learn the IP address of its neighbor. 498 4.2.3. CE Devices Using PPP 500 When the PE learns the IP address of the remote CE, it SHOULD 501 initiate a Configure-Request and set the IP-Address option to 502 the IP address of the remote CE to notify the IP address of the 503 remote CE to the local CE. 505 4.3. Discovery of IP Addresses of IPv6 CE Devices 507 4.3.1. Distinguishing Factors Between IPv4 and IPv6 509 IPv4 uses ARP and inverse ARP to resolve IP address and link 510 layer associations. Since these are dedicated address resolution 511 protocols, and not IP packets, they cannot be carried on an IP 512 pseudowire. They MUST be processed locally and the IPv4 address 513 information they carry signaled between the PEs using the 514 pseudowire control plane. IPv6 uses ICMPv6 extensions to resolve 515 IP address and link address associations. As these are IPv6 516 packets they can be carried on an IP pseudowire and therefore no 517 IPv6 address signaling is required. 519 4.3.2. Requirements for PEs 521 A PE device that supports IPv6 MUST be capable of, 522 - Intercepting ICMPv6 Neighbor Discovery [RFC4861] and 523 Inverse Neighbor Discovery [RFC3122] packets received over 524 the AC as well as over the PW. 525 - Recording the IPv6 interface addresses and CE link-layer 526 addresses present in these packets 527 - Possibly modifying these packets as dictated by the data 528 link type of the egress AC (described in the following 529 sections), and 530 - Forwarding them towards the original destination 532 The PE MUST also be capable of generating packets in order to 533 interwork between Neighbor Discovery (ND) and Inverse Neighbor 534 Discovery (IND). This is specified in Sections 4.3.3 to 4.3.6 535 below. 537 If an IP PW is used to interconnect CEs that use IPv6 Router 538 Discovery [RFC4861], a PE device MUST also be capable of 539 intercepting and processing those Router Discovery packets. This 540 is required in order to translate between different link layer 541 addresses. If a Router Discovery message contains a link layer 542 address, then the PE MAY also use this message to discover the 543 link layer address and IPv6 interface address. This is described 544 in more detail in Section 4.3.7 and Section 4.3.8. 546 The PE device MUST learn a list of CE IPv6 interface addresses 547 for its directly-attached CE and another list of CE IPv6 548 interface addresses for the far-end CE. The PE device MUST also 549 learn the link-layer address of the local CE and be able to use 550 it when forwarding traffic between the local and far-end CEs. 551 The PE MAY also wish to monitor the source link-layer address of 552 data packets received from the CE, and discard packets not 553 matching its learned CE link-layer address. 555 4.3.3. Processing of Neighbor Solicitations 557 A Neighbor Solicitation received on an AC from a local CE SHOULD 558 be inspected to determine and learn an IPv6 interface address 559 (if provided, this will not be the case for Duplicate Address 560 Detection) and any link-layer address provided. The packet MUST 561 then be forwarded over the pseudowire unmodified. A Neighbor 562 Solicitation received over the pseudowire SHOULD be inspected to 563 determine and learn an IPv6 interface address for the far-end 564 CE. If a source link-layer address option is present, the PE 565 MUST remove it. The PE MAY substitute an appropriate link-layer 566 address option, specifying the link-layer address of the PE 567 interface attached to the local AC. Note that if the local AC is 568 Ethernet, failure to substitute a link-layer address option may 569 mean that the CE has no valid link-layer address with which to 570 transmit data packets. 572 When a PE with a local AC, which is of the type point-to-point 573 layer 2 circuit e.g. FR, ATM or PPP, receives a Neighbor 574 Solicitation from a far end PE over the pseudowire, after 575 learning the IP address of the far-end CE, the PE MAY use one of 576 the following procedures: 578 1. Forward the Neighbor Solicitation to the local CE after 579 replacing the source link-layer address with the link- 580 layer address of the local AC. 581 2. Send an Inverse Neighbor Solicitation to the local CE, 582 specifying the far-end CE's IP address and the link-layer 583 address of the local AC. 584 3. Reply to the far end PE with a Neighbor Advertisement, 585 using the IP address of the local CE as the source address 586 and an appropriate link-layer address option that 587 specifies the link-layer address of the local AC. As 588 described later, the IP address of the local CE is learned 589 through IPv6CP in the case of PPP and through Neighbor 590 Solicitation in other cases. 592 4.3.4. Processing of Neighbor Advertisements 593 A Neighbor Advertisement received on an AC from a local CE 594 SHOULD be inspected to determine and learn an IPv6 interface 595 address and any link-layer address provided. The packet MUST 596 then be forwarded over the IP pseudowire unmodified. 598 A Neighbor Advertisement received over the pseudowire SHOULD be 599 inspected to determine and learn an IPv6 interface address for 600 the far-end CE. If a source link-layer address option is 601 present, the PE MUST remove it. The PE MAY substitute an 602 appropriate link-layer address option, specifying the link-layer 603 address of the local AC. Note that if the local AC is Ethernet, 604 failure to substitute a link-layer address option may mean that 605 the local AC has no valid link-layer address with which to 606 transmit data packets. 608 When a PE with a local AC which is of the type point-to-point 609 layer 2 circuit, such as ATM, FR or PPP, receives a Neighbor 610 Advertisement over the pseudowire, in addition to learning the 611 remote CE's IPv6 address, it SHOULD perform the following steps: 613 o If the AC supports Inverse Neighbor Discovery (IND) and 614 the PE had already processed an Inverse Neighbor 615 Solicitation (INS) from local CE, it SHOULD send an 616 Inverse Neighbor Advertisement (INA) on the local AC using 617 source IP address information received in ND-ADV and its 618 own local AC link layer information. 619 o If the PE has not received any Inverse Neighbor 620 Solicitation (INS) from the local CE, and the AC supports 621 Inverse Neighbor Discovery (IND), it SHOULD send an INS on 622 the local AC using source IP address information received 623 in the INA together with its own local AC link layer 624 information. 626 4.3.5. Processing Inverse Neighbor Solicitations (INS) 628 An INS received on an AC from a local CE SHOULD be inspected to 629 determine and learn the IPv6 addresses and the link-layer 630 addresses. The packet MUST then be forwarded over the pseudowire 631 unmodified. 633 An INS received over the pseudowire SHOULD be inspected to 634 determine and learn one or more IPv6 addresses for the far-end 635 CE. If the local AC supports IND (e.g., a switched Frame Relay 636 AC), the packet SHOULD be forwarded to the local CE, after 637 modifying the link-layer address options to match the type of 638 the local AC. 640 If the local AC does not support IND, processing of the packet 641 depends on whether the PE has learned at least one interface 642 address for its directly-attached CE. 644 . If it has learned at least one IPv6 address for the CE, the 645 PE MUST discard the Inverse Neighbor Solicitation (INS) and 646 generate an Inverse Neighbor Advertisement (INA) back into 647 the pseudowire. The destination address of the INA is the 648 source address from the INS, the source address is one of 649 the local CE's interface addresses, and all the local CE's 650 interface addresses that have been learned so far SHOULD be 651 included in the Target Address List. The Source and Target 652 Link-Layer addresses are copied from the INS. In addition, 653 the PE SHOULD generate ND advertisements on the local AC 654 using the IPv6 address of the remote CE and link-layer 655 address of the local PE. 657 . If it has not learned at least one IPv6 and link-layer 658 address of its directly-connected CE, the INS MUST be 659 continued to be discarded until the PE learns an IPv6 and 660 link-layer address from the local CE (through receiving, 661 for example, a Neighbor Solicitation). After this has 662 occurred, the PE will be able to respond to INS messages 663 received over the pseudowire as described above. 665 4.3.6. Processing of Inverse Neighbor Advertisements (INA) 667 An INA received on an AC from a local CE SHOULD be inspected to 668 determine and learn one or more IPv6 addresses for the CE. It 669 MUST then be forwarded unmodified over the pseudowire. 671 An INA received over the pseudowire SHOULD be inspected to 672 determine and learn one or more IPv6 addresses for the far-end 673 CE. 675 If the local AC supports IND (e.g., a Frame Relay AC), the 676 packet MAY be forwarded to the local CE, after modifying the 677 link-layer address options to match the type of the local AC. 679 If the local AC does not support IND, the PE MUST discard the 680 INA and generate a Neighbor Advertisement (NA) towards its local 681 CE. The source IPv6 address of the NA is the source IPv6 address 682 from the INA, the destination IPv6 address is the destination 683 IPv6 address from the INA and the link-layer address is that of 684 the local AC on the PE. 686 4.3.7. Processing of Router Solicitations 688 A Router Solicitation received on an AC from a local CE SHOULD 689 be inspected to determine and learn an IPv6 address for the CE, 690 and, if present, the link-layer address of the CE. It MUST then 691 be forwarded unmodified over the pseudowire. 693 A Router Solicitation received over the pseudowire SHOULD be 694 inspected to determine and learn an IPv6 address for the far-end 695 CE. If a source link-layer address option is present, the PE 696 MUST remove it. The PE MAY substitute a source link-layer 697 address option specifying the link-layer address of its local 698 AC. The packet is then forwarded to the local CE. 700 4.3.8. Processing of Router Advertisements 702 A Router Advertisement received on an AC from a local CE SHOULD 703 be inspected to determine and learn an IPv6 address for the CE, 704 and, if present, the link-layer address of the CE. It MUST then 705 be forwarded unmodified over the pseudowire. 707 A Router Advertisement received over the pseudowire SHOULD be 708 inspected to determine and learn an IPv6 address for the far-end 709 CE. If a source link-layer address option is present, the PE 710 MUST remove it. The PE MAY substitute a source link-layer 711 address option specifying the link-layer address of its local 712 AC. If an MTU option is present, the PE MAY reduce the specified 713 MTU if the MTU of the pseudowire is less than the value 714 specified in the option. The packet is then forwarded to the 715 local CE. 717 4.3.9. Duplicate Address Detection 719 Duplicate Address Detection [RFC4862] allows IPv6 hosts and 720 routers to ensure that the addresses assigned to interfaces are 721 unique on a link. As with all Neighbor Discovery packets, those 722 used in Duplicate Address Detection will simply flow through the 723 pseudowire, being inspected at the PEs at each end, processing 724 is performed as above. However, the source IPv6 address of 725 Neighbor Solicitations used in Duplicate Address Detection is 726 the unspecified address, so the PEs cannot learn the CE's IPv6 727 interface address (nor would it make sense to do so, given that 728 at least one address is tentative at that time). 730 4.3.10. CE address discovery for CEs attached using PPP 732 The IPv6 Control Protocol (IPv6CP) [RFC5072] describes a 733 procedure to establish and configure IPv6 on a point-to-point 734 connection, including the negotiation of a link-local interface 735 identifier. As in the case of IPv4, when such an AC is 736 configured for IP interworking, PPP negotiation is not performed 737 end-to-end between CE devices. Instead, PPP negotiation takes 738 place between the CE and its local PE. The PE performs proxy PPP 739 negotiation and informs the attached CE of the link-local 740 identifier of its local interface using the Interface-Identifier 741 option (0x01). This local interface identifier is used by 742 stateless address auto configuration [RFC4862]. 744 When a PPP link completes IPv6CP negotiations and the PPP link 745 is open, a PE MAY discover the IPv6 unicast address of the CE 746 using any of the mechanisms described above. 748 5. CE IPv4 Address Signaling between PEs 750 5.1. When to Signal an IPv4 address of a CE 752 A PE device advertises the IPv4 address of the attached CE only 753 when the encapsulation type of the pseudowire is IP Layer2 754 Transport (the value 0x0000B, as defined in [RFC4446]). The IP 755 Layer2 transport PW is also referred to as IP PW and is used 756 interchangeably in this document. It is quite possible that the 757 IPv4 address of a CE device is not available at the time the PW 758 labels are signaled. For example, in Frame Relay the CE device 759 sends an inverse ARP request only when the DLCI is active. If 760 the PE signals the DLCI to be active only when it has received 761 the IPv4 address along with the PW FEC from the remote PE, a 762 deadlock situation arises. In order to avoid such problems, the 763 PE MUST be prepared to advertise the PW FEC before the IPv4 764 address of the CE is known and hence uses IPv4 address value 765 zero. When the IPv4 address of the CE device does become 766 available, the PE re-advertises the PW FEC along with the IPv4 767 address of the CE. 769 Similarly, if the PE detects that an IP address of a CE is no 770 longer valid (by methods described above), the PE MUST re- 771 advertise the PW FEC with null IP address to denote the 772 withdrawal of IP address of the CE. The receiving PE then waits 773 for notification of the remote IP address. During this period, 774 propagation of unicast IPv4 traffic is suspended, but multicast 775 IPv4 traffic can continue to flow between the AC and the 776 pseudowire. 778 If two CE devices are locally attached to the PE on disparate AC 779 types (for example, one CE connected to an Ethernet port and the 780 other to a Frame Relay port), the IPv4 addresses are learned in 781 the same manner as described above. However, since the CE 782 devices are local, the distribution of IPv4 addresses for these 783 CE devices is a local step. 785 Note that the PEs discover the IPv6 addresses of the remote CE 786 by intercepting Neighbor Discovery and Inverse Neighbor 787 Discovery packets that have been passed in-band through the 788 pseudowire. Hence, there is no need to communicate the IPv6 789 addresses of the CEs through LDP signaling. 791 If the pseudowire is carrying both IPv4 and IPv6 traffic, the 792 mechanisms used for IPV6 and IPv4 SHOULD NOT interact. In 793 particular, just because a PE has learned a link-layer address 794 for IPv6 traffic by intercepting a Neighbor Advertisement from 795 its directly-connected CE, it SHOULD NOT assume that it can use 796 that link-layer address for IPv4 traffic until that fact is 797 confirmed by reception of, for example, an IPv4 ARP message from 798 the CE. 800 5.2. LDP Based Distribution of CE IPv4 Addresses 802 [RFC4447] uses Label Distribution Protocol (LDP) transport to 803 exchange PW FECs in the Label Mapping message in the Downstream 804 Unsolicited (DU) mode. The PW-FEC comes in two flavors; PWid and 805 Generalized ID FEC elements and has some common fields between 806 them. The discussions below refer to these common fields for IP 807 L2 Interworking encapsulation. 809 In addition to PW-FEC, this document uses an IP Address List TLV 810 (as defined in [RFC5036]) that is to be included in the optional 811 parameter field of the Label Mapping message when advertising 812 the PW FEC for the IP Layer2 Transport. The use of optional 813 parameters in the Label Mapping message to extend the attributes 814 of the PW FEC is specified in [RFC4447]. 816 As defined in [RFC4447], when processing a received PW FEC, the 817 PE matches the PW ID and PW type with the locally configured PW 818 ID and PW Type. If there is a match and if the PW Type is IP 819 Layer2 Transport, the PE further checks for the presence of an 820 Address List TLV [RFC5036] in the optional parameter TLVs. The 821 processing of the Address List TLV is as follows. 823 o If a PE is configured for an AC to a CE enabled for IPv4 824 or dual-stack IPv4/IPv6, the PE SHOULD advertise an 825 Address List TLV with address family type of IPv4 address. 826 The PE SHOULD process the IPv4 Address List TLV as 827 described in this document. The PE MUST advertise and 828 process IPv6 capability using the procedures described in 829 Section 6 below. 830 o If a PE does not receive any IPv4 address in the Address 831 List TLV it MAY assume IPv4 behavior. The address 832 resolution for IPv4 MUST then depend on local manual 833 configuration. In the case of mis-matched configuration 834 whereby one PE has manual configuration while other does 835 not, the IP address to Link Layer address mapping remains 836 unresolved resulting into unsuccessful propagation of IPv4 837 traffic to the local CE. 838 o If a PE is configured for an AC to a CE enabled for IPv6 839 only, the PE MUST advertise IPv6 capability using the 840 procedures described in Section 6 below. In addition, by 841 virtue of not setting the manual configuration for IPv4 842 support, an IPv6 only support is realized. 844 We use the Address List TLV [RFC5036] to signal the IPv4 address 845 of the local CE. This IP Address List TLV is included in the 846 optional parameter field of the Label Mapping message. 848 The Address List TLV is only used for IPv4 addresses. 850 The fields of the IP Address List TLV are set as follows: 852 Length 853 Set to 6 to encompass 2 bytes of Address Family field and 4 854 bytes of Addresses field (because a single IPv4 address is 855 used). 857 Address Family 858 Set to 1 to indicate IPv4 as defined in [RFC5036]. 860 Addresses 861 Contains a single IPv4 address that is the address of the 862 CE attached to the advertising PE. 864 The address in the Addresses field is set to all zeros to denote 865 that the advertising PE has not learned the IPv4 address of its 866 local CE. Any non-zero address value denotes the IPv4 address of 867 the advertising PE's attached CE device. 869 The IPv4 address of the CE is also supplied in the optional 870 parameters field of the LDP Notification message along with the 871 PW FEC. The LDP Notification message is used to signal any 872 change in the status of the CE's IPv4 address. 874 The encoding of the LDP Notification message is as follows. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 |0| Notification (0x0001) | Message Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Message ID | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Status (TLV) | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | IP Address List TLV (as defined above) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | PWId FEC or Generalized ID FEC | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 The Status TLV status code is set to 0x0000002C "IP address of 891 CE", to indicate that an IP Address update follows. Since this 892 notification does not refer to any particular message the 893 Message ID field is set to 0. 895 The PW FEC TLV SHOULD NOT include the interface parameters as 896 they are ignored in the context of this message. 898 6. IPv6 Capability Advertisement 900 A 'Stack Capability' Interface Parameter sub-TLV is signaled by 901 the two PEs so that they can agree which network protocol(s) 902 they SHOULD be using. As discussed earlier, the use of Address- 903 List TLV signifies the support for IPv4 stack, so the 'Stack 904 Capability' sub-TLV is used to indicate whether support for IPv6 905 stack is required on a given IP PW. 907 The 'Stack Capability' sub-TLV is part of the interface 908 parameters. The proposed format for the Stack Capability 909 Interface Parameter sub-TLV is as follows: 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Parameter ID | Length | Stack Capability | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Parameter ID = 0x16 919 Length = 4 921 The Stack Capability field is a bit field. Only one bit is 922 defined in this document. When bit zero (the least significant 923 bit with bitmask 0x0001) is set, it indicates IPv6 stack 924 capability. 926 The presence of stack capability TLV is relevant only when the 927 PW type is IP PW. A PE that supports the IPv6 on an IP PW MUST 928 signal the Stack Capability sub-TLV in the initial Label Mapping 929 message for the PW. The PE nodes compare the value advertised by 930 the remote PE with the local configuration and only use a 931 capability which is supported by both. 933 The behavior of a PE that does not understand an Interface 934 Parameter sub-TLV is specified in section 5.5 of RFC 4447 935 [RFC4447]. 937 In some deployment scenarios, it may be desirable to take a PW 938 operationally down if there is a mismatch of the Stack 939 Capability between the PEs. In other deployment scenarios, an 940 operator may wish the IP version supported by both PEs to fall- 941 back to IPv4 if one of the PEs does not support IPv6. The 942 following procedures MUST be followed for each of these cases. 944 6.1. PW Operational Down on Stack Capability Mis-Match 945 If a PE that supports IPv6 and has not yet sent a Label Mapping, 946 receives an initial Label Mapping message from the far end PE 947 that does not include the 'Stack Capability' sub-TLV, or one is 948 received but it is not set to 'IPv6 Stack Capability' value, 949 then the PE supporting this procedure MUST NOT send a Label 950 Mapping for this PW. 952 If a PE that supports IPv6 has already sent an initial Label 953 Mapping message for the PW and does not receive a 'Stack 954 Capability' sub-TLV in the Label Mapping message from the far- 955 end PE, or one is received but it is not set to 'IPv6 Stack 956 Capability', the PE supporting this procedure MUST withdraw its 957 PW label with the LDP status code meaning "IP Address type 958 mismatch" (Status Code 0x0000004A). However, subsequently if the 959 configuration was to change at the far-end PE and a 'Stack 960 Capability' sub-TLV in the Label Mapping message is received 961 from the far-end PE, the local PE MUST re-advertise the Label 962 Mapping message for the PW. 964 6.2. Stack Capability Fall-back 966 If a PE that supports IPv6 and has not yet sent a Label Mapping, 967 receives an initial Label Mapping from the far end PE that does 968 not include the 'Stack Capability' sub-TLV, or one is received 969 but it is not set to the 'IPv6 Stack Capability' value, then it MAY 970 send a Label Mapping for this PW but MUST NOT include the Stack 971 Capability sub-TLV. 973 If a PE that supports IPv6 and has already sent a Label Mapping 974 for the PW with the 'Stack Capability' sub-TLV, but does not 975 receive a 'Stack Capability' sub-TLV from the far-end PE in the 976 initial Label Mapping message, or one is received but it is not set 977 to the 'IPv6 Stack Capability' value, the PE following this 978 procedure MUST send a Label Withdraw for its PW label with the LDP 979 status code meaning "Wrong IP Address type" (Status Code 0x000004B) 980 followed by a Label Mapping message that does not include the 981 'Stack Capability' sub-TLV. 982 If a Label Withdraw message with the "Wrong IP Address Type" 983 status code is received by a PE, it SHOULD treat this as a 984 normal Label Withdraw, but MUST NOT respond with a Label Release. 985 It MUST continue to wait for the next control message for the PW as 986 specified in section 6.2 of RFC 4447 [RFC4447]. 988 7. IANA Considerations 990 7.1. LDP Status messages 992 This document uses new LDP status codes, IANA already maintains 993 a registry of name "STATUS CODE NAME SPACE" defined by 994 [RFC5036]. The following values are suggested for assignment: 996 0x0000002C "IP Address of CE" 997 0x0000004A "IP Address Type Mismatch" 998 0x0000004B "Wrong IP Address Type" 1000 7.2. Interface Parameters 1002 This document proposes a new Interface Parameters sub-TLV, to be 1003 assigned from the 'Pseudowire Interface Parameters Sub-TLV type 1004 Registry'. The following value is suggested for the Parameter ID: 1006 0x16 "Stack Capability" 1008 IANA is also requested to set up a registry of "L2VPN PE stack 1009 capabilities". This is a 16 bit field. Stack Capability bitmask 1010 0x0001 is specified in Section 6 of this document. The remaining 1011 bitfield values (0x0002,..,0x8000) are to be assigned by IANA using 1012 the "IETF Review" policy defined in [RFC5226]. 1014 L2VPN PE Stack Capabilities: 1016 Bit (Value) Description 1017 =============== ========================================== 1018 Bit 0 (0x0001) - IPv6 stack capability 1019 Bit 1 (0x0002) - Reserved 1020 Bit 2 (0x0004) - Reserved 1021 . 1022 . 1023 . 1025 Bit 14 (0x4000) - Reserved 1026 Bit 15 (0x8000) - Reserved 1027 8. Security Considerations 1029 The security aspect of this solution is addressed for two 1030 planes; control plane and data plane. 1032 8.1. Control Plane Security 1034 Control plane security pertains to establishing the LDP 1035 connection, and to pseudowire signaling and CE IP address 1036 distribution over that LDP connection. For greater security the 1037 LDP connection between two trusted PEs MUST be secured by each 1038 PE verifying the incoming connection against the configured 1039 address of the peer and authenticating the LDP messages using 1040 MD5 authentication, as described in section 2.9 of [RFC5036]. 1041 Pseudowire signaling between two secure LDP peers does not pose 1042 a security issue but mis-wiring could occur due to configuration 1043 error. However, the fact that the pseudowire will only be 1044 established if the two PEs have matching configurations (e.g. PW 1045 ID, PW type, and MTU) provides some protection against mis- 1046 wiring due to configuration errors. 1048 Learning the IP address of the appropriate CE can be a security 1049 issue. It is expected that the Attachment Circuit to the local 1050 CE will be physically secured. If this is a concern, the PE MUST 1051 be configured with IP and MAC address of the CE when connected 1052 with Ethernet or IP and virtual circuit information (DLCI or 1053 VPI/VCI) when connected over Frame Relay or ATM and IP address 1054 only when connected over PPP. During ARP/inverse ARP frame 1055 processing, the PE MUST verify the received information against 1056 local configuration before forwarding the information to the 1057 remote PE to protect against hijacking of the connection. 1059 For IPv6, the preferred means of security is Secure Neighbor 1060 Discovery (SEND) [RFC3971]. SEND provides a mechanism for 1061 securing Neighbor Discovery packets over media (such as wireless 1062 links) that may be insecure and open to packet interception and 1063 substitution. SEND is based upon cryptographic signatures of 1064 Neighbor Discovery packets. These signatures allow the receiving 1065 node to detect packet modification and confirm that a received 1066 packet originated from the claimed source node. SEND is 1067 incompatible with the Neighbor Discovery packet modifications 1068 described in this document. As such, SEND cannot be used for 1069 Neighbor Discovery across an ARP Mediation pseudowire. PEs 1070 taking part in IPv6 ARP Mediation MUST remove all SEND packet 1071 options from Neighbor Discovery packets before forwarding into 1072 the pseudowire. If the CE devices are configured to accept only 1073 SEND Neighbor Discovery packets, this will lead to Neighbor 1074 Discovery failing. Thus, the CE devices MUST be configured to 1075 accept non-SEND packets, even if they treat them with lower 1076 priority than SEND packets. Because SEND cannot be used in 1077 combination with IPv6 ARP Mediation, it is suggested that IPv6 1078 ARP Mediation is only used with secure Attachment Circuits. 1079 An exception to this recommendation applies to an implementation 1080 that supports the SEND Proxy [SPROXY] experimental draft which 1081 allows a device such as PEs to act as an ND proxy as described 1082 in [SPROXY]. 1084 8.2. Data plane security 1086 The data traffic between CE and PE is not encrypted and it is 1087 possible that in an insecure environment, a malicious user may 1088 tap into the CE to PE connection and generate traffic using the 1089 spoofed destination MAC address on the Ethernet Attachment 1090 Circuit. In order to avoid such hijacking, the local PE may 1091 verify the source MAC address of the received frame against the 1092 MAC address of the admitted connection. The frame is forwarded 1093 to the PW only when authenticity is verified. When spoofing is 1094 detected, the PE MUST sever the connection with the local CE, 1095 tear down the PW and start over. 1097 9. Acknowledgements 1099 The authors would like to thank Yetik Serbest, Prabhu Kavi, 1100 Bruce Lasley, Mark Lewis, Carlos Pignataro and other folks who 1101 participated in the discussions related to this document. 1103 10. References 1105 10.1. Normative References 1107 [RFC826] RFC 826, STD 37, D. Plummer, "An Ethernet Address 1108 Resolution protocol: Or Converting Network 1109 Protocol Addresses to 48.bit Ethernet Addresses 1110 for Transmission on Ethernet Hardware". 1112 [RFC2390] RFC 2390, T. Bradley et al., "Inverse Address 1113 Resolution Protocol". 1115 [RFC4447] L. Martini et al., "Pseudowire Setup and 1116 Maintenance using LDP", RFC 4447. 1118 [RFC4446] L. Martini et al,. "IANA Allocations for pseudo 1119 Wire Edge to Edge Emulation (PWE3)", RFC 4446. 1121 [RFC2119] S.Bradner, "Key words for use in RFCs to indicate 1122 requirement levels", RFC 2119. 1124 [RFC5036] L.Anderseen et al., "LDP Specification", RFC 1125 5036. 1127 [RFC4861] Narten, T., Nordmark, E. and W.Simpson, "Neighbor 1128 Discovery for IP Version 6 (IPv6)", RFC 4861. 1130 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery 1131 for Inverse Discovery Specification", RFC 3122. 1133 [RFC4862] Thomson, S. and Narten, T., "IPv6 Stateless 1134 Address Autoconfiguration", RFC 4862. 1136 [RFC3971] Arkko, J. et al., "Secure Neighbor Discovery 1137 (SEND)", RFC 3971. 1139 [RFC5226] Narten, T et al., "Guidelines for Writing an IANA 1140 Considerations Section in RFCs", RFC 5226. 1142 10.2. Informative References 1144 [RFC4664] L. Andersson et al., "Framework for L2VPN", RFC 1145 4664. 1147 [RFC1332] G. McGregor, "The PPP Internet Protocol Control 1148 Protocol (IPCP)", RFC 1332. 1150 [RFC5072] D. Haskin, "IP Version 6 over PPP", RFC 5072. 1152 [RFC925] J.Postel, "Multi-LAN Address Resolution", RFC 1153 925. 1155 [RFC1256] S.Deering, "ICMP Router Discovery Messages", RFC 1156 1256. 1158 [RFC5309] Shen and Zinin, "Point-to-point operation over 1159 LAN in Link State Routing Protocols", RFC 5309. 1161 [SPROXY] S.Krishnan et al., "Secure Proxy ND support for 1162 SEND", draft-ietf-csi-proxy-send-05.txt 1164 11. Authors' Addresses 1166 This document is the combined effort of many who have 1167 contributed, carefully reviewed and provided the technical 1168 clarifications for the document. 1170 Himanshu Shah (editor) 1171 Ciena 1172 Email: hshah@ciena.com 1174 Eric Rosen (editor) 1175 Cisco Systems 1176 Email: erosen@cisco.com 1178 Giles Heron 1179 Cisco Systems (editor) 1180 Email: giheron@cisco.com 1182 Vach Kompella (editor) 1183 Alcatel-Lucent 1184 Email: vach.kompella@alcatel-lucent.com 1186 Matthew Bocci 1187 Alcatel-Lucent 1188 Email: Mathew.bocci@alcatel-lucent.com 1190 Tiberiu Grigoriu 1191 Alcatel-Lucent 1192 Email: Tiberiu.Grigoriu@alcatel-lucent.com 1194 Neil Hart 1195 Alcatel-Lucent 1196 Email: Neil.Hart@alcatel-lucent.com 1198 Andrew Dolganow 1199 Alcatel-Lucent 1200 Email: Andrew.Dolganow@alcatel-lucent.com 1202 Shane Amante 1203 Level 3 1204 Email: Shane@castlepoint.net 1206 Toby Smith 1207 Google 1208 EMail: tob@google.com 1210 Andrew G. Malis 1211 Verizon 1212 EMail: Andy.g.Malis@verizon.com 1214 Steven Wright 1215 Bell South Corp 1216 Email: steven.wright@bellsouth.com 1218 Waldemar Augustyn 1219 Consultant 1220 Email: waldemar@wdmsys.com 1222 Arun Vishwanathan 1223 Juniper Networks 1224 Email: arunvn@juniper.net 1226 Ashwin Moranganti 1227 IneoQuest Technologies 1228 Email: Ashwin.Moranganti@Ineoquest.com 1229 APPENDIX A: 1231 A.1. Use of IGPs with IP L2 Interworking L2VPNs 1233 In an IP L2 interworking L2VPN, when an IGP on a CE connected to 1234 a broadcast link is cross-connected with an IGP on a CE 1235 connected to a point-to-point link, there are routing protocol 1236 related issues that MUST be addressed. The link state routing 1237 protocols are cognizant of the underlying link characteristics 1238 and behave accordingly when establishing neighbor adjacencies, 1239 representing the network topology, and passing protocol packets. 1240 The point to point operations of the routing protocols over a 1241 LAN is discussed in [RFC5309]. 1243 A.1.1. OSPF 1245 The OSPF protocol treats a broadcast link type with a special 1246 procedure that engages in neighbor discovery to elect a 1247 designated and a backup designated router (DR and BDR 1248 respectively) with which each other router on the link forms 1249 adjacencies. However, these procedures are neither applicable 1250 nor understood by OSPF running on a point-to-point link. By 1251 cross-connecting two neighbors with disparate link types, an IP 1252 L2 interworking L2VPN may experience connectivity issues. 1254 Additionally, the link type specified in the router LSA will not 1255 match for the two cross-connected routers. 1257 Finally, each OSPF router generates network LSAs when connected 1258 to a broadcast link such as Ethernet, receipt of which by an 1259 OSPF router which believes itself to be connected to a point-to- 1260 point link further adds to the confusion. 1262 Fortunately, the OSPF protocol provides a configuration option 1263 (ospfIfType), whereby OSPF will treat the underlying physical 1264 broadcast link as a point-to-point link. 1266 It is strongly recommended that all OSPF protocols on CE devices 1267 connected to Ethernet interfaces use this configuration option 1268 when attached to a PE that is participating in an IP L2 1269 Interworking VPN. The point-to-point operation of the routing 1270 protocol over 1271 A.1.2. RIP 1273 RIP protocol broadcasts RIP advertisements every 30 seconds. If 1274 the multicast/broadcast traffic snooping mechanism is used as 1275 described in section 4.1, the attached PE can learn the local CE 1276 router's IP address from the IP header of its advertisements. No 1277 special configuration is required for RIP in this type of Layer 1278 2 IP Interworking L2VPN. 1280 A.1.3. IS-IS 1282 The IS-IS protocol does not encapsulate its PDUs in IP, and 1283 hence cannot be supported in IP L2 Interworking L2VPNs.