ietf-corpus

rfc-4719

Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)

R. Aggarwal (Editor), M. Townsley (Editor), M. Dos Santos (Editor)
date2006-11 streamIETF areartg wgl2tpext statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc4719 doi10.17487/RFC4719
This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]

updated by

Extracted elements (21)

design-rationale §4

FCS is not transported across Ethernet or Ethernet VLAN PWs, so payload integrity transparency may be lost. To achieve payload integrity transparency, the L2TPv3 session can utilize IPsec as specified in RFC 3931 Section 4.1.3.

mpls, vpn, security, ipsec

design-rationale §3.1

The Ethernet PW is homogeneous with respect to packet encapsulation — both ends must be either untagged or tagged. Heterogeneous services can be provided via NSP functionality at the ingress/egress LCCE, which is outside the PW scope.

mpls, vpn

design-rationale §2.2

The Outgoing Call model (OCRQ/OCRP/OCCN) has not been found applicable for PW applications; only the Incoming Call three-way handshake is used for Ethernet PW session establishment.

mpls, vpn

interoperability-note §4

For Ethernet 802.1Q VLAN transport, the ingress LCCE MAY consider the 802.1p user priority field for traffic classification, and the egress LCCE MAY consider the DS field of the encapsulating IP header when rewriting the VLAN user priority field.

mpls, vpn, diffserv, qos

interoperability-note §4

The Ethernet PW only supports homogeneous Ethernet frame types across the PW; both ends must be either tagged or untagged. NSP functionality can provide heterogeneous support but this is outside the scope of the document.

mpls, vpn

normative-requirement §2.2 MUST

A subsequent circuit status change of the Ethernet port or VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI control messages, and must indicate an existing circuit.

mpls, vpn

normative-requirement §2.2 MUST

An implementation MUST support a Remote End Identifier of four octets known to both LCCEs either by manual configuration or some other means.

mpls, vpn

normative-requirement §3.2 MAY

Data packet sequencing MAY be enabled for Ethernet PWs, and the sequencing mechanisms described in RFC 3931 MUST be used for signaling sequencing support.

mpls, vpn

normative-requirement §2.1 MUST

For connecting an Ethernet port to another Ethernet port, the PW Type MUST be 'Ethernet port'; for connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type MUST be 'Ethernet VLAN'.

mpls, vpn

normative-requirement §2.3.1 MUST

If the corresponding L2TPv3 session is down, the PW associated with it MUST be shut down.

mpls, vpn

normative-requirement §3.3 MUST

Implementations MUST follow the fragmentation and reassembly guidelines in RFC 3931 Section 4.1.4 and RFC 4623 with respect to MTU handling.

mpls, vpn, ip

normative-requirement §5 SHOULD

LCCEs SHOULD monitor for congestion using explicit congestion notification or by measuring packet loss. When severe congestion is detected, the Ethernet PW SHOULD be halted by tearing down the L2TP session via a CDN message.

mpls, vpn, congestion, qos

normative-requirement §2.2 MUST

The Circuit Status AVP MUST be included in ICRQ and ICRP to indicate circuit status. For ICRQ and ICRP, it MUST indicate that the circuit status is for a new circuit.

mpls, vpn

normative-requirement §3.1 MUST

The entire Ethernet frame, without the preamble or FCS, is encapsulated in L2TPv3 and sent as a single packet by the ingress LCCE, regardless of whether a VLAN tag is present.

mpls, vpn

normative-requirement §2.2 MUST

The Pseudowire Type AVP MUST be present in the ICRQ. The Remote End Identifier AVP MUST be present in the ICRQ so the remote LCCE can determine which PW to associate with the L2TP session.

mpls, vpn

normative-requirement §2.3.2 MUST

The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP, with the exception of the initial ICRQ, ICRP, and CDN messages.

mpls, vpn

normative-requirement §2.1 MUST

Two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP Control Connection first, and an Ethernet PW Type must be included in the Pseudowire Capabilities List.

mpls, vpn

protocol-element §2.3.3

The Circuit Status AVP is a 16-bit mask with the A (Active) bit indicating whether the Ethernet interface is ACTIVE (1) or INACTIVE (0), and the N (New) bit indicating whether the circuit is new (1) or existing (0). Reserved bits MUST be set to 0 when sending and ignored on receipt.

mpls, vpn

registry §7

IANA allocated two Ethernet Pseudowire Types in the L2TPv3 Pseudowire Types registry: 0x0004 for Ethernet VLAN Pseudowire Type and 0x0005 for Ethernet Pseudowire Type.

registry, mpls, vpn

security-consideration §6

Ethernet over L2TPv3 is subject to all general security considerations outlined in RFC 3931. No additional security mechanisms beyond those in RFC 3931 are defined in this document.

security, mpls, vpn

wire-format §3.3

The L2TPv3 session header overhead N ranges from 4-16 octets for L2TPv3 over IP, and 16-28 octets for L2TPv3 over UDP, comprising Session ID (4 octets), Cookie (0/4/8 octets), and optional L2-Specific Sublayer (0/4 octets). The Flags/Ver/Res field (4 octets) applies only to the UDP case.

mpls, vpn, udp, ip