idnits 2.17.1 draft-ietf-l2tpext-pwe3-ip-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 834. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 15, 2007) is 6099 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-l2vpn-arp-mediation-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2TPEXT Working Group C. Pignataro 3 Internet-Draft W. Luo 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 16, 2008 August 15, 2007 7 Signaling and Encapsulation for the Transport of IP over L2TPv3 8 draft-ietf-l2tpext-pwe3-ip-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 16, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 42 protocol for tunneling a variety of data link protocols over IP 43 networks. This document defines the control messaging, signaling 44 procedures and encapsulation specifics of how to tunnel IPv4 and IPv6 45 packets directly over L2TPv3. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Control Connection Establishment . . . . . . . . . . . . . . . 5 61 3. Session Establishment and IP Interface Status Notification . . 6 62 3.1. L2TPv3 Session Establishment . . . . . . . . . . . . . . . 6 63 3.2. L2TPv3 Session Teardown . . . . . . . . . . . . . . . . . 8 64 3.3. L2TPv3 Session Maintenance . . . . . . . . . . . . . . . . 8 65 3.4. Use of Circuit Status AVP for IP Transport Pseudowires . . 8 67 4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Data Packet Encapsulation . . . . . . . . . . . . . . . . 9 69 4.2. Data Packet Sequencing . . . . . . . . . . . . . . . . . . 10 70 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 10 72 5. Point-to-Point Address Resolution Considerations . . . . . . . 11 73 5.1. Static Address Resolution . . . . . . . . . . . . . . . . 11 74 5.2. Dynamic ARP Mediation . . . . . . . . . . . . . . . . . . 12 75 5.2.1. CE IP Address AVP usage . . . . . . . . . . . . . . . 13 77 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 15 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 8.1. Pseudowire Type . . . . . . . . . . . . . . . . . . . . . 16 83 8.2. Control Message Attribute Value Pairs (AVPs) . . . . . . . 16 84 8.3. Result Code AVP Values . . . . . . . . . . . . . . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 9.1. Preventing forwarding loops with Ethernet and VLAN ACs . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 Intellectual Property and Copyright Statements . . . . . . . . . . 20 96 1. Introduction 98 The Layer 2 Tunneling Protocol - Version 3 (L2TPv3) [RFC3931] defines 99 a base protocol for Layer 2 Tunneling over IP networks. This 100 document describes the specifics necessary for tunneling IPv4 and 101 IPv6 packets over L2TPv3. Such emulated circuits are referred to as 102 IP Transport Pseudowires (IP PWs). 104 One application of IP PWs is to interconnect Attachment Circuits of 105 disparate Layer 2 protocols by locally terminating the Layer 2 and 106 transporting IP datagrams directly over L2TPv3 sessions. This 107 document refers to these Attachment Circuits as IP interfaces. 109 Protocol specifics defined in this document for L2TPv3 IP PWs include 110 those necessary for simple point-to-point (e.g., between two L2TPv3 111 nodes) IP PW signaling, IP datagram encapsulation, address resolution 112 considerations and simple interface up and interface down 113 notifications. This document also defines a new AVP to be used in 114 point-to-point IP PWs. 116 The reader is expected to be very familiar with the terminology and 117 protocol constructs defined in [RFC3931]. 119 1.1. Abbreviations 121 AC Attachment Circuit 123 CE Customer Edge (Typically also the L2TPv3 Remote System). 125 IP PW IP Transport Pseudowire 127 LAC L2TP Access Concentrator (See [RFC3931]) 129 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 131 NSP Native Service Processing 133 PE Provider Edge (Typically also the LCCE). 135 PW Pseudowire 137 1.2. Requirements 139 The Pseudowire architecture [RFC3985] defines a Native Service 140 Processing (NSP) function to restrict a Pseudowire to homogeneous 141 operation by having the NSP perform actions that need knowledge of 142 the semantics of the payload. 144 The following figure depicts the PW termination and NSP function 145 within an LCCE: 147 +---------------------------------------+ 148 | LCCE | 149 +-+ +-----+ +------+ +------+ +-+ 150 |P| |IP PW| | PW | | PSN | |P| 151 AC (IP <==>|h|<=>| NSP |<=>| Term |<=>|Tunnel|<=>|h|<==> PSN 152 Interface) |y| | | | | | | |y| 153 +-+ +-----+ +------+ +------+ +-+ 154 | | 155 +---------------------------------------+ 157 Figure 1: Requirements for IP PWs 159 In IP Transport, the NSP function acts as the interface between the 160 AC and the PW termination, and performs the following operations: 162 o Terminates the data link layer. 164 o Extracts IP datagrams from the Layer 2 frames and injects them 165 into the PW. 167 o Drops non-IP payloads. 169 o Performs Address Resolution mediation and proxy functions 170 (optionally). 172 To the right of the NSP in Figure 1, only IP datagrams are forwarded 173 to the PW termination point. The PW termination point receives raw 174 IP datagrams and delivers them unaltered to the PW termination point 175 on the remote LCCE, providing an IP Transport emulation service. 176 Consequently, in one application, the IP PW emulation allows for 177 interworking between Attachment Circuits of different Layer 2 178 technologies. 180 2. Control Connection Establishment 182 In order to tunnel IP datagrams over an IP packet switched network 183 using L2TPv3, an L2TPv3 Control Connection MUST first be established 184 as described in [RFC3931]. The L2TPv3 SCCRQ Control Message and 185 corresponding SCCRP Control Message MUST include the IP Transport 186 Pseudowire Type of 0x000B (See IANA Considerations Section), in the 187 Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931]. 188 Signaling such a capability in the control messages indicates that 189 L2TP sessions support IP PWs. 191 An LCCE MUST be able to uniquely identify itself in the SCCRQ and 192 SCCRP messages via a globally unique value. This is advertised via 193 the structured Router ID AVP [RFC3931], though the unstructured 194 Hostname AVP [RFC3931] MAY be used to identify LCCEs as well. 196 3. Session Establishment and IP Interface Status Notification 198 This section specifies how the status of the IP interface is reported 199 between two LCCEs, and the associated L2TP session creation and 200 deletion that occurs. 202 3.1. L2TPv3 Session Establishment 204 Associating an IP interface with a PW and its transition to "Ready" 205 or "Up" results in the establishment of an L2TP session via the 206 standard three-way handshake described in Section 3.4.1 of [RFC3931]. 207 For the purposes of this discussion, the action of locally 208 associating an IP interface with a PW by local configuration or 209 otherwise is referred to as "provisioning" the interface. The 210 transition of the interface to "ready" or "up" will be referred to as 211 the interface becoming ACTIVE. The transition of the interface to 212 "not-ready" or "down" will be referred to as the interfacing becoming 213 INACTIVE. 215 An LCCE MAY initiate the session immediately upon association with an 216 IP interface, or wait until the interface becomes ACTIVE before 217 attempting to establish an L2TP session. 219 The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], 220 Attribute Type 68, MUST be present in the ICRQ messages and MUST 221 include the Pseudowire Type of 0x000B for IP PWs. 223 The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ, 224 ICRP messages and MAY be present in the SLI message for IP PWs. 226 The Interface Maximum Transmission Unit AVP defined in Section 4.3 of 227 [RFC4667], Attribute Type 91, MAY be present in the ICRQ and ICRP 228 messages. When an LCCE receives an Interface MTU AVP with an MTU 229 value different from its own, it MAY respond with a CDN with a result 230 code of 23 indicating Mismatching interface MTU. 232 Following is an example of the L2TP messages exchanged for an IP PW 233 which is initiated after an IP interface is provisioned and becomes 234 ACTIVE. 236 LCCE (LAC) A LCCE (LAC) B 237 ------------------ ------------------ 238 IP Interface Provisioned 239 IP Interface Provisioned 240 IP Interface ACTIVE 242 ICRQ (status = 0x03) ----> 244 IP Interface ACTIVE 246 <---- ICRP (status = 0x03) 248 L2TP session established, 249 OK to send data into tunnel 251 ICCN -----> 252 L2TP session established, 253 OK to send data into tunnel 255 In the example above, an ICRQ is sent after the interface is 256 provisioned and becomes ACTIVE. The Circuit Status AVP (see 257 Section 3.4) indicates that this link is ACTIVE and New (0x03). The 258 Remote End ID AVP [RFC3931] MUST be present in the ICRQ in order to 259 identify the IP Transport AC (together with the identity of the LCCE 260 itself as defined in Section 2) to associate the L2TP session with. 261 The Remote End ID AVP defined in [RFC3931] is of opaque form and 262 variable length, though an implementation MUST at a minimum support 263 use of an unstructured four-octet value that is known to both LCCEs 264 (either by direct configuration, or some other means). The exact 265 method of how this value is configured, retrieved, discovered, or 266 otherwise determined at each LCCE is outside the scope of this 267 document. 269 As with the ICRQ, the ICRP is sent only after the associated IP 270 interface transitions to ACTIVE as well. If LCCE B had not been 271 provisioned for the interface identified in the ICRQ, a CDN would 272 have been immediately returned indicating that the associated link 273 was not provisioned or available at this LCCE. LCCE A SHOULD then 274 exhibit a periodic retry mechanism. If so, the period and maximum 275 number of retries MUST be configurable. 277 An Implementation MAY send an ICRQ or ICRP before an IP interface is 278 ACTIVE, as long as the Circuit Status AVP reflects that the link is 279 INACTIVE and an SLI is sent when the IP interface becomes ACTIVE (see 280 Section 3.3). 282 The ICCN is the final stage in the session establishment, confirming 283 the receipt of the ICRP with acceptable parameters to allow 284 bidirectional traffic. 286 3.2. L2TPv3 Session Teardown 288 In the event a link is removed (unprovisioned) at either LCCE, the 289 associated L2TP session MUST be torn down via the CDN message defined 290 in Section 3.4.3 of [RFC3931]. General Result Codes regarding L2TP 291 session establishment are defined in [RFC3931]. 293 3.3. L2TPv3 Session Maintenance 295 IP PWs over L2TP make use of the Set Link Info (SLI) control message 296 defined in [RFC3931] to signal IP interface status notifications 297 between PEs. The SLI message is a single message that is sent over 298 the L2TP control channel, signaling the interface state change. 300 The SLI message MUST be sent any time there is a status change of the 301 Active value identified in the Circuit Status AVP. The only 302 exception to this is the initial ICRQ, ICRP and CDN messages which 303 establish and teardown the L2TP session itself. The SLI message may 304 be sent from either PE at any time after the first ICRQ is sent (and 305 perhaps before an ICRP is received, requiring the peer to perform a 306 reverse Session ID lookup). 308 All sessions established by a given control connection utilize the 309 L2TP Hello facility defined in [RFC3931] for session keepalive. This 310 gives all sessions basic dead peer and path detection between PEs. 312 3.4. Use of Circuit Status AVP for IP Transport Pseudowires 314 IP Transport reports Circuit Status with the Circuit Status AVP 315 defined in [RFC3931], Attribute Type 71. 317 For reference, this AVP is shown below: 319 0 1 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Reserved |N|A| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The Value is a 16 bit mask with the two least significant bits 326 defined and the remaining bits reserved for future use. Reserved 327 bits MUST be set to 0 when sending, and ignored upon receipt. 329 The N (New) bit SHOULD be set to one (1) if the Circuit Status 330 indication is for a new IP interface, zero (0) otherwise. 332 The A (Active) bit indicates whether the IP interface is ACTIVE (1) 333 or INACTIVE (0). 335 4. Encapsulation 337 4.1. Data Packet Encapsulation 339 IP PWs use the default encapsulations defined in [RFC3931] for 340 demultiplexing, sequencing, and flags. 342 The L2TPv3 encapsulation carrying an IP datagram is as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Session ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Cookie (optional, maximum 64 bits)... 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 ... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Default L2-Specific Sublayer (optional) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | IP datagram | 356 . . 357 . . 358 . . 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Because Layer 2 frames of different encapsulation are normalized into 363 IP datagrams when transporting over the IP over L2TP Pseudowire, it 364 becomes possible to interconnect a pair of disparate attachment 365 circuits. In consequence, the IP PW does not have any operational 366 mode contraints, (i.e., it can either operate in an "interface to 367 interface" fashion, "virtual circuit to virtual circuit" fashion, or 368 hybrid "interface to virtual circuit" fashion). For example one AC 369 can be a Frame-Relay DLCI while the other AC can be a PPP interface; 370 or one AC can be an ATM PVC, while the other AC can be an ethernet 371 VLAN. 373 The Layer 2 is terminated on the LAC, the IPv4 or IPv6 datagram 374 extracted and transported over the IP PW. If a non-IP packet is 375 received over the AC, it MUST be dropped and not transported over the 376 PW. 378 4.2. Data Packet Sequencing 380 Data Packet Sequencing MAY be enabled for IP PWs. The sequencing 381 mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for 382 signaling sequencing support. IP PW over L2TP MUST request the 383 presence of the L2TPv3 Default L2-Specific Sublayer defined in 384 Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request 385 its presence at all times. 387 It should be noted that the following two values for the Data 388 Sequencing AVP, Attribute Type 70, have the exact same meaning for IP 389 PWs: 391 0 - No incoming data packets require sequencing. 393 1 - Only non-IP data packets require sequencing. 395 As such, the value of 1 SHOULD NOT be used for IP PWs. Additionally, 396 the requirement of sequencing MUST be signaled with the following 397 value: 399 2 - All incoming data packets require sequencing. 401 This value implies that all IPv4 and IPv6 datagrams transported 402 include sequencing as described in Section 4.6.1 of [RFC3931]. 404 4.3. MTU Considerations 406 With L2TPv3 as the tunneling protocol, the packet resulting from the 407 encapsulation is N bytes longer than the raw IP datagram transported. 409 The value of N depends on the following fields: 411 L2TP Session Header: 412 Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) 413 Session ID - 4 octets 414 Cookie Size - 0, 4 or 8 octets 415 L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) 417 Hence the range for N in octets is: 419 N = 4-16, for L2TPv3 data messages are over IP; 420 N = 16-28, for L2TPv3 data messages are over UDP; 421 (N does not include the IP header). 423 The MTU and fragmentation implications resulting from this are 424 discussed in Section 4.1.4 of [RFC3931]. 426 5. Point-to-Point Address Resolution Considerations 428 Different data link layers implement different address resolution 429 mechanisms. 431 The following sections describe the two address resolution 432 operational modes: the REQUIRED Static Address Resolution mode (see 433 Section 5.1) and the OPTIONAL Dynamic ARP Mediation mode (see 434 Section 5.2). 436 5.1. Static Address Resolution 438 An IP PW is intended to provide point-to-point connectivity, in one 439 application between two CE devices. When dynamic ARP mediation 440 procedures are not used, the following considerations and 441 requirements apply to the specific data link layers that connect PE 442 and CE devices. 444 o Ethernet 445 Because only one CE device is expected to be attached to the 446 Ethernet port, the LAC SHOULD act as proxy ARP for the segment 447 responding with its own MAC address to all ARP requests. The LAC 448 MUST provide a configuration option to turn off this behavior, for 449 the cases where more than one CE device may be connected to the 450 Ethernet port. Additionally, the LAC MAY provide an option to 451 configure the remote CE's IP address and when doing so the LAC 452 MUST respond with its own MAC address (source hardware address) to 453 ARP requests for this configured IP address (destination protocol 454 address) only. If neither of these options are provided, address 455 resolution is achieved by configuring static ARP entries for the 456 locally attached devices. 458 o VLAN 459 Same as Ethernet. 461 o PPP 462 The LAC MUST provide an option to configure the remote CE's IP 463 address and use it in IPCP negotiations. 465 o Frame-Relay 466 Because it is expected that the CE device treats the link as 467 point-to-point, no specific address resolution requirements are 468 needed. For the cases where the CE device may treat the link as 469 multi-point, the LAC MAY provide an option to configure the remote 470 CE's IP address and use it when replying to Inverse ARP messages 471 from the local CE; additionally, when the CE device treats the 472 link as multi-point, address resolution can be achieved by a 473 static Inverse ARP configuration at the CE device. 475 o ATM 476 Same as Frame-Relay 478 o HDLC 479 The CE MUST treat the link as point-to-point. 481 Note that for Ethernet and VLAN links, the PE device MUST discover 482 the MAC address of the locally attached CE device, and MAY use the 483 procedures in [I-D.ietf-l2vpn-arp-mediation] to do so. This 484 discovery is a local process that does not affect interoperability. 486 5.2. Dynamic ARP Mediation 488 The IP Transport NSP function MAY implement dynamic ARP mediation 489 mechanisms and procedures to signal the CE IP addresses between PE 490 devices for point-to-point IP PWs, and SHOULD follow 491 [I-D.ietf-l2vpn-arp-mediation] if doing so. The dynamic ARP 492 mediation defined in [I-D.ietf-l2vpn-arp-mediation] outlines a three- 493 step procedure for PE devices: 495 1. Discover the IP addresses of the locally attached CE device. 497 2. Distribute those IP Addresses to the remote PE. 499 3. Notify the locally attached CE of the remote CE's IP address. 501 The dynamic ARP mediation procedures for L2TPv3 IP PWs make use of 502 steps 1 and 3 and define the signaling procedures for step 2. 504 Additionally, if the AC data link layer is Ethernet or VLAN, the PE 505 device also needs to discover the MAC address of the locally attached 506 CE device and MAY use the procedures in 507 [I-D.ietf-l2vpn-arp-mediation]. 509 When using the Dynamic ARP Mediation signaling procedures for L2TPv3 510 IP PWs, the CE IP Address AVP, Attribute Type AVP-TBD-1, is used to 511 distribute the CE IP address to the remote PE. 513 The Attribute Value field for this AVP has the following format: 515 CE IP Address AVP (ICRQ, ICRP, SLI) 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Address Family | CE IP Address ... 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ... (4 or 16 octets) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 The Address Family is a two octet quantity containing a value from 526 IANA's "Address Family Numbers" in [IANA.address-family-numbers] that 527 encodes the address contained in the CE IP Address field. 529 The following address encodings to be used in this AVP are hereby 530 defined: 532 +----------------+----------------------------+ 533 | Address Family | Address Encoding | 534 +----------------+----------------------------+ 535 | IPv4 (1) | 4 octet full IPv4 address | 536 | IPv6 (2) | 16 octet full IPv6 address | 537 +----------------+----------------------------+ 539 Table 1 541 The CE IP Address encodes the IP address of the CE attached to the 542 advertising PE. The encoding depends on the Address Family field, 543 either a 4 octet IPv4 address or a 16 octet IPv6 address. 545 The Length of this AVP is either 12 (when encoding an IPv4 address) 546 or 24 (when encoding an IPv6 address). The M bit for this AVP MUST 547 be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 548 0). 550 5.2.1. CE IP Address AVP usage 552 The presence of this AVP in an ICRQ or ICRP message indicates that 553 the LCCE is willing to perform ARP mediation procedures. A null CE 554 IP Address value indicates that the LCCE has not yet learned the IP 555 address of his attached Remote System for the given address family. 556 In this case, this AVP MUST be included in SLI messages sent 557 asynchronously when the IP address of the local Remote System is 558 discovered, with a non-null value denoting the IP address of the 559 Remote System. 561 The following example depicts the L2TP signaling messages exchanged 562 for an IP PW establishment using the dynamic ARP Mediation procedures 563 assuming an IPv4 address family. 565 LCCE (LAC) A LCCE (LAC) B 566 ------------------ ------------------ 567 IP Interface Provisioned 568 with ARP Mediation 569 IP Interface Provisioned 570 with ARP Mediation 571 IP Interface ACTIVE 573 ICRQ (IP address = NULL) ----> 575 IP Interface ACTIVE 577 <---- ICRP (IP address = NULL) 579 L2TP session established, 580 OK to send data into tunnel 582 ICCN -----> 583 L2TP session established, 584 OK to send data into tunnel 586 CE A's IP Address learned. 588 SLI (IP address = CE_A) ----> 590 CE B's IP Address learned. 592 <---- SLI (IP address = CE_B) 594 Likewise, this AVP MAY be re-advertised with a null CE IP Address 595 value in an SLI message to indicate that the CE IP Address has become 596 unavailable or is no longer valid. This mechanism serves as a CE IP 597 Address withdrawal. 599 Continuing with the same example, the following figure depicts the 600 L2TP signaling message sent when PE A discovers that CE A's IP 601 Address is no longer valid. 603 LCCE (LAC) A LCCE (LAC) B 604 ------------------ ------------------ 605 CE A's IP Address invalidated. 607 SLI (IP address = NULL) ----> 609 If an ICRQ or ICRP message is received containing the CE IP Address 610 AVP and the receiving LCCE is not capable, configured or willing to 611 perform ARP mediation procedures, the session MUST be rejected via a 612 CDN mesage with the following General Result Code: 614 RC-TBD1: Mismatching ARP Mediation 616 If an ICRP message is received lacking the CE IP Address AVP when the 617 respective ICRQ was sent including this AVP, the session MUST be 618 rejected via a CDN mesage with the same General Result Code. 620 6. Applicability Statement 622 This document defines the specifics necessary for tunneling IP 623 datagrams over L2TPv3 IP PWs. Some characteristics of the IP 624 Transport Pseudowires are: 626 o The length of the resulting L2TPv3 packet is longer than the 627 encapsulated IP packet as detailed in Section 4.3. The resulting 628 MTU and fragmentation implications and procedures are discussed in 629 Section 4.1.4 of [RFC3931] and in Section 5 of [RFC4623]. 631 o Sequencing may be enabled in the IP PW by using the Default L2- 632 Specific Sublayer to detect lost, duplicate, or out-of-order 633 packets on a per-session basis (see Section 4.2). 635 o To allow for payload integrity checking transparency on IP PWs 636 using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can 637 utilize IPSec as specified in Section 4.1.3 of [RFC3931]. 639 In one application of IP PWs, the mechanism described in this 640 document can be used to provide L2TPv3 sessions that connects unlike 641 data link technologies (e.g., Ethernet and PPP) in an interworking 642 fashion when the access service payloads are known beforehand to 643 consist only of IP datagrams. This is achieved by terminating the 644 Layer 2 protocol in the LCCE and transporting only the IP datagrams 645 over L2TPv3, such that the L2TPv3 session links uniform Pseudowire 646 terminations (i.e. IP Transport Pseudowire Type) and an NSP function 647 provides translation from the AC before presentation to the PW and 648 viceversa. The ACs carrying IP-framed can be interfaces (such as 649 PPP, HDLC or Ethernet interfaces) or virtual circuits (such as Frame- 650 Relay or ATM virtual circuits). IP PWs can in turn operate in an 651 "interface to interface" mode, "virtual circuit to virtual circuit" 652 mode or a hybrid "interface to virtual circuit" mode, because the 653 Pseudowire payload is normalized and the NSP function performs 654 operations between the Pseudowire termination and the Attachment 655 Circuit. 657 Because disparate attachment circuit types may be used in conjunction 658 with an IP Pseudowire, there is an increased likelihood that an 659 L2TPv3 session will be established to carry traffic between 660 attachment circuits with mismatched MTU sizes, and that partial 661 communication between CE devices over the pseudowire will result. 662 The possibility of mismatched MTUs is avoided if the LCCEs advertise 663 their respective attachment circuit MTU sizes using the Interface 664 Maximum Transmission Unit AVP as described in Section 3.1. 666 7. Acknowledgements 668 This document heavily borrows and adapts format and text from the 669 "HDLC Frames over L2TPv3" Internet-Draft, and we would like to 670 acknowledge its authors and contributors. 672 Many thanks to Maria Alice Dos Santos, George Wilkie, Bill Storer and 673 Mark Lewis for providing a thorough review and valuable comments and 674 suggestions. 676 8. IANA Considerations 678 8.1. Pseudowire Type 680 The signaling mechanisms defined in this document rely upon the 681 assignment of an IP Transport Pseudowire Type (see Pseudowire 682 Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 683 Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space 684 created as part of publication of [RFC3931]). The IP Transport 685 Pseudowire Type is defined in Section 2 of this specification: 687 0x000B IP Transport Pseudowire Type. 689 8.2. Control Message Attribute Value Pairs (AVPs) 691 A new AVP appears in Section 5.2 which needs assignment by IANA as 692 described in Section 2.2 of [RFC3438]. 694 AVP-TBD-1: CE IP Address AVP 696 8.3. Result Code AVP Values 698 A new L2TP Result Code for the CDN message appears in Section 5.2.1 699 which need assignment by IANA as described in Section 2.3 of 700 [RFC3438]. 702 RC-TBD1: Mismatching ARP Mediation 704 9. Security Considerations 706 The IP Transport over L2TPv3 is subject to the security 707 considerations defined in [RFC3931] and 708 [I-D.ietf-l2vpn-arp-mediation]. Additionaly, Section 9.1 includes a 709 specific consideration to IP Transport Pseudowires using the Static 710 Address Resolution procedures not present when carrying other data 711 link types. 713 9.1. Preventing forwarding loops with Ethernet and VLAN ACs 715 IP PWs are intended to provide point-to-point connectivity between 716 two CE devices, and therefore it is expected that the CE devices be 717 configured with a subnet mask of at least 30-bits. In an IP PW where 718 the ACs are either Ethernet or Ethernet VLAN, an undesired side 719 effect arises if the CE device is configured with a subnet mask 720 shorter than 30-bits and the LCCE acts as a proxy ARP for the segment 721 responding to all ARP requests with its own MAC Address: If an IP 722 Address falls within the prefix in the segment but is not at either 723 end of the PW, IP datagrams destined to it would loop back and forth 724 until the TTL field expires. To prevent this unwanted behavior, the 725 mechanisms defined in Section 5.1 MUST be used. They are copied 726 verbatim as follows: 728 Because only one CE device is expected to be attached to the 729 Ethernet port, the LAC SHOULD act as proxy ARP for the segment 730 responding with its own MAC address to all ARP requests. The LAC 731 MUST provide a configuration option to turn off this behavior, for 732 the cases where more than one CE device may be connected to the 733 Ethernet port. Additionally, the LAC MAY provide an option to 734 configure the remote CE's IP address and when doing so the LAC 735 MUST respond with its own MAC address (source hardware address) to 736 ARP requests for this configured IP address (destination protocol 737 address) only. If neither of these options are provided, address 738 resolution is achieved by configuring static ARP entries for the 739 locally attached devices. 741 10. References 743 10.1. Normative References 745 [I-D.ietf-l2vpn-arp-mediation] 746 Shah, H., "ARP Mediation for IP Interworking of Layer 2 747 VPN", draft-ietf-l2vpn-arp-mediation-08 (work in 748 progress), July 2007. 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 754 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 756 10.2. Informative References 758 [IANA.address-family-numbers] 759 Internet Assigned Numbers Authority, "Address Family 760 Numbers", 761 . 763 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 764 Internet Assigned Numbers Authority (IANA) Considerations 765 Update", BCP 68, RFC 3438, December 2002. 767 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 768 Edge (PWE3) Architecture", RFC 3985, March 2005. 770 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 771 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 772 August 2006. 774 [RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) 775 Extensions for Layer 2 Tunneling Protocol (L2TP)", 776 RFC 4667, September 2006. 778 Authors' Addresses 780 Carlos Pignataro 781 Cisco Systems, Inc. 782 7200 Kit Creek Road 783 PO Box 14987 784 Research Triangle Park, NC 27709 785 USA 787 Email: cpignata@cisco.com 788 Wei Luo 789 Cisco Systems, Inc. 790 170 West Tasman Drive 791 San Jose, CA 95134 792 USA 794 Email: luo@cisco.com 796 Full Copyright Statement 798 Copyright (C) The IETF Trust (2007). 800 This document is subject to the rights, licenses and restrictions 801 contained in BCP 78, and except as set forth therein, the authors 802 retain all their rights. 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 807 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 808 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 809 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Intellectual Property 814 The IETF takes no position regarding the validity or scope of any 815 Intellectual Property Rights or other rights that might be claimed to 816 pertain to the implementation or use of the technology described in 817 this document or the extent to which any license under such rights 818 might or might not be available; nor does it represent that it has 819 made any independent effort to identify any such rights. Information 820 on the procedures with respect to rights in RFC documents can be 821 found in BCP 78 and BCP 79. 823 Copies of IPR disclosures made to the IETF Secretariat and any 824 assurances of licenses to be made available, or the result of an 825 attempt made to obtain a general license or permission for the use of 826 such proprietary rights by implementers or users of this 827 specification can be obtained from the IETF on-line IPR repository at 828 http://www.ietf.org/ipr. 830 The IETF invites any interested party to bring to its attention any 831 copyrights, patents or patent applications, or other proprietary 832 rights that may cover technology that may be required to implement 833 this standard. Please address the information to the IETF at 834 ietf-ipr@ietf.org. 836 Acknowledgment 838 Funding for the RFC Editor function is provided by the IETF 839 Administrative Support Activity (IASA).