idnits 2.17.1 draft-shah-ppvpn-arp-mediation-00.txt: ** The Abstract section seems to be numbered -(186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(456): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(474): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(476): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 23 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 188 has weird spacing: '...ty with disc...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L2VPN-KOMPELLA' is mentioned on line 239, but not defined == Missing Reference: 'MARTINI-TRANS' is mentioned on line 373, but not defined == Missing Reference: 'RFC 1256' is mentioned on line 262, but not defined == Missing Reference: 'MARTINI-TRAN' is mentioned on line 337, but not defined -- Looks like a reference, but probably isn't: '8' on line 393 == Missing Reference: 'MARTINI-ENCAP' is mentioned on line 434, but not defined == Unused Reference: 'L2VPN-ENCAP' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'L2VPN-TRANS' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'PROXY-ARP' is defined on line 656, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-01 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-Kompella' == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-04 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. 'L2VPN-ENCAP') == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-08 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'L2VPN-TRANS') ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. 'PROXY-ARP') Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Himanshu Shah 3 Prabhu Kavi 4 PPVPN Working Group Tenor Networks 5 Internet Draft 6 draft-shah-ppvpn-arp-mediation-00.txt Eric Rosen 7 Cisco Systems 8 February 2002 9 Expires: August 2002 Waldemar Augustyn 10 Consultant 12 Giles Heron 13 PacketExchange,Ltd 15 Sunil Khandekar 16 Vach Kompella 17 TiMetra Networks 19 Vijay Aggarwal 20 Gotham Networks 22 Jeremy Brayley 23 Rafael Francis 24 Laurel Networks 26 Arun Vishwanathan 27 Force10 Networks 29 Ashwin Moranganti 30 Appian Communications 32 ARP Mediation for IP interworking of Layer 2 VPN 34 1.0 Status of this Memo 36 This document is an Internet-Draft and is in full conformance with 37 all provisions of Section 10 of RFC2026. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 Shah, et al. Expires August 2002 1 53 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 2.0 Abstract 60 This draft addresses an issue in a particular kind of Layer 2 VPN, 61 which provides point-to-point connectivity for IP traffic only. In 62 this kind of VPN it is possible to form heterogeneous point-to-point 63 links, where the two ends of the link use different technologies, 64 e.g., one end is Ethernet and the other is Frame Relay or ATM. If 65 two IP systems are connected via a heterogeneous point-to-point link, 66 each may be using different address learning techniques, e.g., one is 67 using ARP and the other Inverse ARP. It is up to the Provider Edge 68 routers to make these different techniques interwork. This draft 69 specifies the procedures, which the Provider Edge routers should 70 perform in order to allow correct operation across heterogeneous 71 point-to-point links. 73 2.1 ID Summary 75 SUMMARY 77 This ID describes a mechanism by which PE devices learn the IP 78 address of each locally attached CE device and distributes these to 79 other PEs in order to mediate between the address resolution 80 mechanisms used by the CE devices. The ID also points out 81 difficulties, and in some cases, the inoperability of IGPs on the CE 82 devices when interconnected by PE devices using IP L2 interworking 83 VPN solution. 85 RELATED DOCUMENTS 86 Draft-kompella-ppvpn-l2vpn-01.txt. 87 draft-ietf-ppvpn-l2vpn-arch-00.txt 88 draft-rosen-ppvpn-l2-signaling-00.txt 89 draft-martini-l2circuit-trans-mpls-08.txt 90 draft-heinanen-inarp-uni-01.txt 92 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 94 Belongs in PPVPN 96 WHY IS IT TARGETED AT THIS WG 98 This document describes a mechanism to assist in Provider- 99 Provisioned Layer 2 VPNs. 101 JUSTIFICATION 103 The IP L2 interworking VPN solution described in [L2VPN-Kompella] 104 introduces the concept of Layer 2 IP interworking between disparate 105 Layer 2 media (e.g. Ethernet and Frame Relay). However, it does not 107 Shah, et al. Expires August 2002 2 108 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 110 address how address resolution protocols should be handled between 111 these disparate media types. This document describes how the PEs 112 should mediate between the different address resolution protocols 113 that each CE device uses. Also, there are issues when IGP on a 114 point-to-point link CE is interconnected with IGP on a multi- 115 access/broadcast link CE. This document outlines these issues. 117 3.0 Overview 119 A heterogeneous circuit is defined as a virtual circuit between two 120 CE devices that consists of two disparate attachment VCs as the 121 endpoints of an Emulated VC. For example, a CE device on Ethernet is 122 attached to an emulated VC whose other end point is a CE device on 123 frame relay. The attachment VC in this example could then be a VLAN 124 tag on Ethernet interface emulated to the attachment VC of a frame 125 relay DLCI on the other end. While such heterogeneous circuits do 126 not work in general, they can be made to work on the assumption that 127 all their traffic is IP traffic and the Emulated VC performs inter- 128 working function for the IP data frames. 130 The [L2VPN-Kompella] ID describes methodologies that allow 131 heterogeneous layer 2 circuits to be mapped through MPLS tunnels to 132 remote sites that belong to the same VPN. In this "IP L2 133 interworking" scheme the inter-working functions consist of 134 stripping layer 2 header (e.g. Ethernet MAC header) of the data 135 packet at ingress, dispatching the raw IP packets to the egress, and 136 prepending the appropriate Layer 2 header (e.g. RFC 2427 header for 137 frame relay) before sending it to the attached CE device. 139 The problem in such IP L2 Interworking scheme is that, for example, 140 if a CE1 is an Ethernet-attached router, it expects to learn the IP 141 address of its neighbor from a multicast routing control packet, and 142 then expects to do ARP to learn the MAC address. However, if CE2 is 143 attached via frame relay, it expects to use Inverse ARP to learn the 144 IP address of its neighbor, and it does not send, nor may it respond 145 to ARP messages over the frame relay interface. For CE1 and CE2 to 146 inter-work correctly, PE1 and PE2 will need to mediate the address 147 learning and resolution process. 149 One option would be to require each CE to have a static 150 configuration of the IP addresses of all remote CEs. However, this 151 is unwieldy and should be avoided whenever possible. A better 152 approach would be to have the service provider network automatically 153 mediate between the various ARP messages. In this document, we 154 propose that the PE devices capture the address resolution protocol 155 messages sent by the CE, and use this information to perform a 156 mediation function between different ARP message formats. The 157 methods of performing this mediation function are described in this 158 document. In some cases, this mediation may not be possible, and 159 these situations are also detailed in this document. 161 Note that the PEs are capturing the CE�s IP addresses information 162 solely for the purpose of mediating between different ARP formats. 164 Shah, et al. Expires August 2002 3 165 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 167 The end-to-end service remains a point-to-point layer 2 service 168 where forwarding decisions are solely based upon the circuit 169 identifier (e.g. DLCI). 171 4.0 Introduction 173 In the traditional layer 2 VPNs, the customer facing links are 174 required to be of the same data link type for each "circuit". The PE 175 device is only responsible for shuttling the data traffic from the 176 link connecting to the local CE, over an MPLS core, and to the link 177 connecting to the remote CE. This requirement of homogenous data 178 link type is somewhat restrictive in building various network 179 topologies. In [L2VPN-Kompella], it is observed that if all the 180 traffic is known to be IP traffic, it is possible to relax this 181 restriction by decapsulating the IP packet from one data link 182 encapsulation and simply reencapsulating it in the other. 184 However, [L2VPN-Kompella] does not address all the issues. For 185 example, consider a situation where the service provider network 186 creates a �circuit� between an Ethernet VLAN tag and a Frame Relay 187 DLCI. Unless static ARP is used, the CE router connected to the 188 Frame Relay interface precedes its IP activity with discovery of 189 its neighbor�s IP address using the inverse ARP protocol [INVARP]. 190 Similarly, the CE router on an Ethernet precedes its direct IP 191 communication by binding its neighbor�s MAC address to its IP 192 address via ARP protocol [ARP]. However, the Inverse ARP on a 193 point-to-point link is seeking disjoint information from an ARP on a 194 broadcast link. 196 The PE router is a logical place to perform a mediation function 197 between these related but incompatible address resolution protocols. 198 Performing this function in the PE simplifies the operation of the 199 CE, and keeps pseudo-wire interworking transparent to the CE. 201 For each IP Layer 2 interworking circuit, there are three logical 202 steps to performing this address mediation: 204 1. Have the PEs discover the attached CE�s IP addresses. 205 2. Distribute this IP address to the PE at the remote end of the 206 circuit. 207 3. Notify the attached CE about the remote CE�s IP address. 209 In some cases these steps are disjoint while in other cases they 210 could be part of a single step based on whether the IP address of 211 the remote CE device was received along with the cross-connect 212 information. 214 It is important to note that the dynamic learning and distribution 215 of the attached CE�s IP addresses is possible only for some data 216 link technologies. For other data links, static configuration cannot 217 be avoided. However, this ARP mediation addresses the most common 219 Shah, et al. Expires August 2002 4 220 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 222 methods of creating Layer 2 VPNs, and therefore should be widely 223 useful. 225 5.0 IP address discovery of local CE device 227 For each Layer 2 IP interworking circuit, the PE creates and fills 228 in a tuple consisting of the following: 230 1. Attached CE�s IP address 231 2. Circuit Info 232 3. Remote CE�s IP address 234 This information is gathered using the mechanisms described below. 236 The rest of this section describes how IP address of the locally 237 attached CE is learned. Section 6 describes how the learned IP 238 address may be distributed to the remote PE using the signaling 239 mechanisms either of [L2VPN-KOMPELLA] or [MARTINI-TRANS]. Section 7 240 describes how remote PEs process the received cross-connect 241 information with or without IP address for IP address resolution 242 purposes with local CE. 244 5.1 Ethernet data link 246 PE device attached to Ethernet data link is either cognizant or 247 noncognizant of IEEE802.1Q based VLAN tagging. When practicing 248 802.1Q based VLAN tagging, each VLAN tag could represent a circuit 249 or a pseudo virtual wire that connects to exactly one remote 250 endpoint through a pair of PE devices. 252 Alternatively, the entire Ethernet port may be treated as a single 253 endpoint that is connected to a single remote endpoint via a pair of 254 PE devices. 256 In either case, only one Ethernet IP end station (CE device) is 257 presumed to be present for participation within the IP interworking 258 based Layer 2 VPN. 260 In order to learn the IP address of the CE device for a given 261 Ethernet circuit (i.e. Ethernet port or Ethernet port + VLAN), PE 262 device may execute router discovery protocol [RFC 1256] whereby a 263 router discovery request (ICMP - router solicitation) message is 264 sent on each circuit using source IP address as zero. The IP address 265 of the CE device is extracted from the router discovery response 266 (ICMP - router advertisement) message from the CE and associated 267 with the circuit. 269 The use of router discovery mechanism by the PE is optional. The 270 alternatives could include gleaning source address field of any 271 broadcasts to IP multicast or broadcast address and making sure that 272 only one router on the local LAN is sending such broadcasts. It is 273 also possible to simply wait for the local router to generate ARP 275 Shah, et al. Expires August 2002 5 276 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 278 request for its neighbor. The Ethernet address and protocol address 279 can then be gleaned from the request. 281 Once IP address of the CE device is learned, PE periodically 282 generates ARP request message as a mean to verify the existence of 283 CE�s IP address and it�s binding to the Ethernet MAC address. The 284 absence of response from the CE device for a given number of retries 285 is used as a cause for a withdrawal of IP address advertisement to 286 the remote PE and entering into the address resolution phase to 287 rediscover the attached CE�s IP address. 289 5.2 Frame Relay data link 291 A frame relay attached CE device generates inverse ARP request to 292 obtain the IP address of the neighbor when the associated DLCI 293 becomes active. Traditionally, a DLCI becomes active when the DCE 294 signals LMI status active message as a result of associated PVC path 295 becoming operational. 297 A PE device attached to a CE, connected either directly or through a 298 set of frame relay switches, plays the role of an intermediate 299 network node for cross-connect purposes. To a frame relay endnode 300 (i.e. CE), presence of intermediate frame relay switches and pair of 301 PE separated by MPLS cloud along with a remote CE on perhaps 302 Ethernet, is transparent and appear as though Ethernet based CE is 303 remote end point of frame relay PVC path. 305 However, for IP L2 interworking VPN purposes, Ethernet CE and frame 306 relay CE are two IP end stations and it becomes necessary for PE to 307 play a role in address resolution to keep each end stations unaware 308 of data link inconsistency. 310 When processing frame relay inverse ARP request for a DLCI, if the 311 PE does not have IP address associated with the cross-connect from 312 the remote PE, it does not respond, but notes the IP address of the 313 frame relay attached CE and the DLCI information. If the remote IP 314 address were available, it responds with inverse ARP reply. 315 Subsequently, when the IP address of the remote CE becomes 316 available, PE may initiate the inverse ARP request as a mean to 317 notify the neighbor of the IP address. 319 5.3 ATM data link 321 A CE device attached to ATM data link treats each PVC as an IP 322 subnet. PE participates in RFC 2225 defined inverse ATM ARP. When 323 processing inATMARP request for a PVC, if the PE does not have IP 324 address associated with the cross-connect from the remote PE, it 325 does not respond, but notes the IP address of the ATM attached CE 326 and the PVC information. If the remote IP address were available it 327 would respond with inATMARP reply. Subsequently, when the IP address 328 of the remote CE becomes available, PE may initiate the inATMARP 329 request as a mean to notify the neighbor of the IP address. 331 Shah, et al. Expires August 2002 6 332 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 334 6.0 IP address distribution between PE 336 There are two cross-connect information distribution mechanisms 337 defined each in [L2VPN-Kompella] and [MARTINI-TRAN]. Following 338 sections discusses how these signaling protocols are extended to 339 distribute the associated IP address information. 341 6.1 BGP based distribution [L2VPN-Kompella] 343 The [L2VPN-Kompella] draft has defined the MP-BGP NLRI for the L2VPN 344 cross-connect information. The NLRI contains label block offset, 345 label base and the size (i.e. length of circuit status vector sub- 346 TLV) tuple that provides a set of contiguous labels starting from 347 label base to correspond to a set of remote CE-Ids starting from 348 label block offset. 350 We propose an IP address sub-TLV for this NLRI that accompany this 351 tuple. The type value is TBD. The length is same as length of 352 circuit status vector sub-TLV. The value field contains the length 353 number of 4-byte fields where each field is an IP address that 354 corresponds one-to-one with the labels represented by the label base 355 and length field. The PE device should note the label to IP address 356 association by iterating through each IP field value in order. 358 6.2 LDP based distribution [MARTINI-TRANS] 360 The [MARTINI-TRANS] uses LDP transport to exchange layer-2 cross- 361 connect information for a given VPN. The cross-connect information 362 is represented as a VC FEC element that LDP protocol distributes to 363 remote peer in downstream-unsolicited mode. This document proposes 364 extensions to VC FEC element to support the IP L2 inteworking as a 365 new VPN type and to include the IP address information. 367 6.2.1 IP L2 Interworking encapsulation 369 The IP L2 interworking VPN type is advertised in the "VC-type" field 370 of the VC FEC as the value 0x000C. 372 The "interface parameter" field in the VC FEC is defined in 373 [MARTINI-TRANS] as follows. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Parameter ID | Length | Variable Length Value | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Variable Length Value | 381 | " | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Shah, et al. Expires August 2002 7 385 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 387 The parameter ID is defined as follows: 388 Parameter ID Length Description 390 0x01 4 Interface MTU in octets. 391 0x02 4 Maximum Number of concatenated ATM cells. 392 0x03 up to 82 Optional Interface Description string. 393 0x04 4 CEM [8] Payload Bytes. 394 0x05 4 CEM options. 396 The Length field is defined as the length of the interface 397 parameter including the parameter id and length field itself. 399 We propose additional parameter for the parameter ID. 401 0x06 4 IP address of CE 403 The IP address interface parameter contains the IP address 404 associated with the advertised VC-id. If IP address is not known, 405 this interface parameter may not be present in the advertisement. If 406 present, it may contain the IP address value as 0.0.0.0. In either 407 case, receiving PE processes the information as IP address 408 association unknown for the advertised VC-ID. 410 6.2.2 Data forwarding 412 When participating in IP L2 interworking VPN, the receiving PE must 413 check the received access VC type against the local access (or 414 attachment) VC type for the matching cross-connect. When the access 415 VC types are identical, IP L2 interworking aspects of the cross- 416 connect should be ignored and revert to traditional data forwarding 417 mechanisms as defined for such VC type in [MARTINI-ENCAP]. 419 However, when access VC types are different and the VC type field is 420 IP L2 Interworking, the mechanisms defined in this document should 421 be followed. 423 The IP L2 Interworking permits only IP data packets to be exchanged 424 over the emulated VC. The following description from [L2VPN- 425 Kompella] shows how data packets are handled by the ingress and 426 egress PE. 428 At the ingress PE, an L2 frame's L2 header is completely stripped off 429 and is carried over as an IP packet through a tunnel to the egress 430 PE. The forwarding decision is still based on the L2 circuit 431 information of the incoming IP frame. At the egress PE, the IP 432 packet is encapsulated back in an L2 frame and transported over to 433 the destination CE. The forwarding decision at the egress PE is 434 based on the VC label as discussed in [MARTINI-ENCAP]. The L2 435 technology between egress PE and CE is independent of the L2 436 technology between ingress PE and CE. 438 Shah, et al. Expires August 2002 8 439 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 441 6.3 IP address distribution operation 443 A PE device advertises the IP address of the attached CE only when 444 the encapsulation type of the VPN is IP L2 interworking. It is quite 445 possible that the IP address of a CE device is not available at the 446 time of advertisements. For example, in frame relay the CE device 447 dispatches inverse ARP request only when the DLCI is active and if 448 the PE signals DLCI to be active only when it has received the 449 cross-connect information from the remote PE, a chicken and egg 450 situation arises. In order to avoid such problems, the PE must 451 advertise the cross-connect information with or without (i.e. no IP 452 TLV or 0.0.0.0) the corresponding IP address. When the IP address of 453 the CE device does become available, a new advertisement is 454 generated with updated IP address field value. 456 Similarly, If PE detects invalidation of CE�s IP address (by methods 457 described above), PE may re-advertise the cross-connect information 458 without IP address or with IP address as zero to denote the 459 withdrawal of IP address. The receiving PE may then wait for the IP 460 address information from the remote PE before enabling the unicast 461 IP traffic flow. 463 7.0 How CE learns IP address of remote CE 465 Once the PE has learned IP address to label association from the 466 remote PE�s cross-connect advertisement, it can either initiate the 467 address resolution request or respond to the request from the 468 attached CE device. 470 7.1 Ethernet data link 472 When PE learns about remote CE�s IP address from the layer 2 VPN 473 advertisement (as described above), it may or may not know local 474 CE�s IP address. If local CE�s IP address is not known, it must wait 475 for the arrival of either IGP broadcast packet or RDP response or an 476 ARP request from the local CE. If, however, local CE�s IP address is 477 already known, PE may choose to generate unsolicited ARP 478 (gratuitous) message to notify the local CE about the association of 479 remote CE�s IP address and the PE�s own MAC address. 481 In either case, as and when an ARP request is generated by the local 482 CE, PE must proxy ARP response using his own MAC address as the 483 source hardware address and remote CE�s IP address as source 484 protocol address. PE must respond only to those ARP requests whose 485 destination protocol address matches to remote CE�s IP address. 487 If two CE devices are locally attached to PE where one CE is 488 connected to Ethernet data link and other to Frame relay data link 489 for example, the IP addresses are learned in the same manner as 490 described above. However, since the CE devices are local, the 491 distribution of IP addresses for these CE devices is a local step. 493 Shah, et al. Expires August 2002 9 494 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 496 7.2 Frame relay data link 498 If a PE has received new cross-connect information from the remote 499 PE, the corresponding local DLCI may not be active. PE should use 500 the cross-connect information to activate the DLCI via LMI and 501 schedule the inverse ARP request. The PE may choose to delay 502 generation of inverse ARP request in order for attached CE to 503 generate the request first. However, it is possible that PE may 504 never get inverse ARP request nor may it get the response to its own 505 request. This may be the result of IP protocol not being enabled on 506 CE device at the time when DLCI was activated. This is not an issue 507 since cross connect information exchange is not predicated on 508 learning of CE�s IP address. As and when the IP protocol is enabled 509 on the CE device, an inverse ARP request would be forthcoming. 511 It is also possible that CE router may never generate inverse ARP 512 request as it may already be configured with IP address of the 513 remote end point and/or inverse ARP is disabled or not supported. If 514 inverse ARP protocol is supported (disabled or not), CE router would 515 still respond to inverse ARP request even when it already knows the 516 IP address of the remote end station. However, if inverse ARP 517 protocol is not supported, PE is required to be configured with the 518 IP address of the attached CE router in order for the PE to 519 distribute the IP address as part of the cross-connect information 520 to the remote PE. 522 7.3 ATM data link 524 The PE device should generate the inAtmARP request when the IP 525 address of the remote cross-connected CE device becomes available. 526 The role of PE device in handling address resolution for the IP L2 527 interworking cross-connect for local ATM PVC is similar to that of 528 local frame relay PVC. 530 It is also possible that ATM end station is participating in RFC 531 1577 style dynamic ARP mechanisms using the ATM ARP server. This 532 document leaves the option of participation with ATM ARP server to 533 vendor�s implementation. As always, static configuration of the 534 local CE�s IP address is another option that PE may use. 536 8.0 Multipoint IGP to point-to-point IGP issues 538 In IP L2 interworking VPN, when an IGP on CE connected to a 539 broadcast link is cross-connected with an IGP on CE connected to a 540 point-to-point link, there are routing protocol related issues that 541 must be addressed. The link state routing protocols are cognizant of 542 the underlying link characteristics and behave accordingly when 543 establishing neighbor adjacencies, representing the network topology 544 and passing protocol packets. 546 8.1 OSPF 548 Shah, et al. Expires August 2002 10 549 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 551 OSPF protocol treats broadcast link type with a special procedure 552 that engages in neighbor discovery to elect a designated and a 553 backup designated (DR and BDR respectively) router to form adjacency 554 with. However, these procedures are neither applicable nor 555 understood by OSPF running on a point-to-point link. By cross- 556 connecting two neighbors with disparate link types in IP L2 557 interworking VPN causes this confusion that must be avoided. 559 Additionally, link type specified in router LSA would appear 560 different for two routers that are supposedly to be present on the 561 same link. Also, OSPF router generates network LSAs when connected 562 to broadcast link such as Ethernet, receipt of which by an OSPF 563 router on the point-to-point link adds to the confusion. 565 Fortunately, OSPF protocol provides a configuration option 566 (ospfIfType), whereby OSPF would treat the underlying physical 567 broadcast link as a point-to-point link. 569 It is strongly recommended that all OSPF protocols on CE devices 570 connected to Ethernet data link must use this configuration when 571 attached PE that is participating in IP L2 Interworking VPN. 573 8.2 IS-IS 575 IS-IS protocol sends LAN Hello PDU (IIH packet) on Ethernet link 576 with MAC address and IP address of the CE device. It expects 577 neighbor to insert his own MAC and IP address in the response. If 578 the neighbor is cross-connected to a point-to-point remote CE 579 device, the LAN Hello PDU would be silently discarded. Similarly, 580 Hello PDU on the point-to-point link does not contain any MAC 581 address, which confuses the cross-connected neighbor on Ethernet 582 link. 584 Thus, IS-IS protocol on the CE devices presents problem when 585 interconnected by disparate data link types in IP L2 interworking 586 VPN environment. There are some mechanisms defined in draft-ietf- 587 isis-igp-p2p-over-lan-00.txt to accommodate point-to-point behavior 588 over broadcast network. The feasibility of such technique to solve 589 this problem is under review. 591 8.3 RIP 593 RIP protocol broadcasts RIP advertisements every 30 seconds. If 594 multicast snooping mechanism is used, PE can learn the advertising 595 router�s IP address from the IP header of the advertisement. No 596 special configuration is required for RIP in this type of layer 2 IP 597 interworking VPN. 599 9.0 Conclusion 601 The three step procedure; discovering IP address of local CE device, 602 distribution of the IP address to remote PE and notifying the IP 604 Shah, et al. Expires August 2002 11 605 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 607 address to the attached CE device; described in this document 608 provides for reduced configuration of the PE devices used for IP- 609 interworking solution. 611 There are cases where the manual configuration of the IP address is 612 not avoidable. These cases relate to either some of the data links 613 like, Cisco HDLC, that do not support the address resolution 614 protocol or that address resolution is disabled by, for example, use 615 of unnumbered interface in the CE device. 617 It is also important to note that IP address changes on the CE 618 devices may require manual interventions (e.g. soft reset of the 619 attached port) on the PE device. 621 For most common cases, the procedure described in this document 622 enhances the IP interworking solution of [L2VPN-Kompella]. 624 10.0 Acknowledgements 626 Authors would like to thank Tim Mancour, Bruce Lasley, Bill 627 Townsend, Arnold Sodder and other folks within Tenor who 628 participated in discussions related to this draft. 630 11.0 Security Considerations 632 The security aspects of this solution will be discussed at a later 633 time. 635 11.0 References 637 [L2VPN-Kompella] Kompella et al., "MPLS based Layer 2 VPNs", draft- 638 kompella-ppvpn-l2vpn-01.txt, November 2001. 640 [L2VPN-ENCAP] Martini et al., "Encapsulation Methods for Transport 641 of Layer 2 Frames over MPLS", draft-martini-l2circuit-encap-mpls- 642 04.txt, November 2001, (work in progress). 644 [L2VPN-TRANS] Martini et al., "Transport of Layer 2 frames over 645 MPLS", draft-martini-l2circuit-trans-mpls-08.txt. November 2001, 646 (work in progress) 648 [INVARP] T.Bradley et al., "Inverse Address Resolution Protocol", 649 RFC2390, September 1998. 651 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol: Or 652 Converting Network Protocol Addresses to 48.bit Ethernet 653 Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, 654 November 1982. 656 [PROXY-ARP] Postel, J., "Multi-LAN Address Resolution", RFC 925, 657 October 1984. 659 Shah, et al. Expires August 2002 12 660 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 662 Author's Address 664 Himanshu Shah 665 Tenor Networks 666 100 Nagog Park 667 Acton, MA 01720 668 Email: hshah@tenornetworks.com 670 Prabhu Kavi 671 Tenor Networks 672 100 Nagog Park 673 Acton, MA 01720 674 Email: Prabhu_kavi@tenornetworks.com 676 Eric Rosen 677 Cisco Systems 678 300 Apollo Drive, 679 Chelmsford, MA 01824 680 Email: erosen@cisco.com 682 Waldemar Augustyn 683 Email: waldemar@nxp.com 685 Giles Heron 686 PacketExchange Ltd. 687 The Truman Brewery 688 91 Brick Lane 689 LONDON E1 6QL 690 United Kingdom 691 Email: giles@packetexchange.net 693 Sunil Khandekar and Vach Kompella 694 TiMetra Networks 695 274 Ferguson Dr. 696 Mountain View, CA 94043 697 Email: sunil@timetra.com 698 Email: vkompella@timetra.com 700 Vijay Aggarwal 701 Gotham Networks 702 15 Discovery Way 703 Acton, MA 01720 704 Email: vaggarwal@gothamnetworks.com 706 Jeremy Brayley and Rafael Francis 707 Laurel Networks 708 Omega Corporate Center 709 1300 Omega drive 710 Pittsburgh, PA 15205 711 Email: jbrayley@laurelnetworks.com 712 Email: rfrancis@laurelnetworks.com 714 Shah, et al. Expires August 2002 13 715 Internet Draft draft-shah-ppvpn-arp-mediation-00.txt 717 Arun Vishwanathan 718 Force10 Networks 719 1440 McCarthy Blvd., 720 Milpitas, CA 95035 721 Email: arun@force10networks.com 723 Ashwin Mornaganti 724 Appian Communications 725 35 Nagog Park 726 Acton, MA 01720 727 Email: amoranganti@appiancom.com 729 Shah, et al. Expires August 2002 14