ietf-corpus

rfc-2590

Transmission of IPv6 Packets over Frame Relay Networks Specification

A. Conta, A. Malis, M. Mueller
date1999-05 streamIETF areaint wgion statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc2590 doi10.17487/RFC2590
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]

updated by

Extracted elements (26)

design-rationale §2

Although Frame Relay allows distinct maximum frame sizes for input and output directions, this specification assumes symmetry (same MTU for both) for simplification. Implementations may also enforce the Frame Relay maximum frame size at the interface (card) level, applied uniformly to all PVCs and SVCs on that interface.

ip

design-rationale §2

Configuring the IPv6 MTU above 4080 octets is strongly discouraged because CRC16 protects frames up to only ~4088 bytes, and CRC32 (needed for larger frames) is not yet widely deployed or mandatory in Frame Relay Forum and ITU-T standards.

ip

design-rationale §4

Each VC termination point on a Frame Relay interface is treated as a 'pseudo-interface' or 'logical-interface', enabling a distinct IPv6 autoconfigured address (including a link-local address) to be associated with each DLCI. This models the fact that each VC acts as an independent virtual-link.

ip

design-rationale §7

Multicast emulation by flooding ND packets to all VCs works well with PVCs. A dedicated mesh of PVCs or point-to-multipoint PVCs MAY be configured for multicast-only traffic as an optimization, since Frame Relay networks do not provide link-layer native multicasting.

ip, multicast

interoperability-note §7

Because Frame Relay lacks a native multicast mechanism, IPv6 multicast must be emulated. A node MUST send frames carrying ND multicast packets (to all-node and solicited-node multicast addresses) to all VCs on the Frame Relay interface.

ip, multicast

interoperability-note §8

DLCIs have strictly local significance at each Frame Relay interface. The DLCI used by the sender to identify a VC may differ from the DLCI the receiver uses to identify the same VC, so received DLCI values in ND messages cannot be used directly without receiver-side rewriting.

ip

interoperability-note §1

The mechanisms in this document apply to both Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs), and to both point-to-point and point-to-multipoint Frame Relay virtual circuits.

ip

normative-requirement §4 SHOULD

A DLCI-based interface identifier SHOULD be generated upon successfully establishing a VC (PVC or SVC). Until a VC is established and a DLCI is assigned, the unspecified DLCI (all 24 bits set to 1) MUST be used.

ip

normative-requirement §4.1 MUST

If a Frame Relay interface has an E.164 or X.121 number or an NSAP address, the 'Mid' field MUST be filled with the value derived from it (BCD or binary, truncated to 38 bits), rather than using locally administered numbers.

ip

normative-requirement §8 MUST

If a received ND Solicitation message contains a Source Link-layer Address option with a DLCI, the message MUST undergo Frame Relay-specific preprocessing before being passed to the ND protocol engine. This preprocessing replaces the received DLCI with the locally significant DLCI of the VC on which the frame arrived.

ip

normative-requirement §6 MUST

In the DLCI Format option, the unused bits in the first two octets of the Link-Layer Address field MUST be set to zero on transmit and MUST be ignored by the receiver.

ip

normative-requirement §2 SHOULD

The default IPv6 MTU for a Frame Relay interface is 1592 octets, derived from the typical Frame Relay maximum frame size of at least 1600 octets. A smaller value may be configured but never below the IPv6 minimum MTU.

ip

normative-requirement §4 MUST

The DLCI field within the interface identifier MUST be extended with leading zeros to 24 bits. If a DLCI is not known, all 24 bits of the DLCI field MUST be set to 1 (the 'unspecified DLCI' value).

ip

normative-requirement §3 MUST

The encoding of the IPv6 protocol identifier in SNAP-encapsulated messages MUST follow the specifications of those protocols and [ASSNUM], and is not affected by this document's NLPID encapsulation.

ip

normative-requirement §6 SHOULD

The use of the Override 'O' bit in ND advertisement messages containing DLCI or Frame Relay Address format link-layer addresses SHOULD be consistent with [ND] specifications. Implementations should override a cached address format only with the same type of address format.

ip

protocol-element §4

The Frame Relay pseudo-interface identifier is a 64-bit value composed of three fields: a 2-bit EUI bits field (U/L=0, I/G=0), a 38-bit Mid field providing uniqueness, and a 24-bit DLCI field holding the 10-, 17-, or 23-bit DLCI zero-padded to 24 bits.

ip

protocol-element §4.1

The 'Mid' field (38 bits) can be generated via two mechanisms: (b.1) merging a 6-bit random number, a 16-bit Frame Relay Node Identifier, and a 16-bit Frame Relay Link Identifier; or (b.2) truncating the BCD-encoded E.164/X.121 number or binary NSAP address to 38 bits.

ip

protocol-element §6

Two distinct Source/Target Link-layer Address option formats are defined for use in Neighbor Discovery and Inverse Neighbor Discovery messages on Frame Relay: the 'DLCI Format' (used on already-established VCs) and the 'Frame Relay Address Format' (used to establish new SVCs via E.164, X.121, or NSAP).

ip

security-consideration §9

Security protection for Neighbor Discovery and Inverse Neighbor Discovery messages on Frame Relay links is provided by IPv6 IPsec mechanisms (Security Architecture [IPSEC], Authentication Header [IPSEC-Auth], and ESP [IPSEC-ESP]).

ip, security, ipsec

security-consideration §9

The interface identifier generation mechanisms provide uniqueness at the virtual-circuit level. Protection against duplicate addresses is achieved through IPv6 Stateless Autoconfiguration Duplicate Address Detection, applied repeatedly until the generated identifier and link-local address are unique on the VC.

ip, security

security-consideration §9 MUST

To avoid IPsec Authentication Header verification failure, the Frame Relay-specific preprocessing of a received ND Solicitation message that contains a DLCI format Source Link-layer Address option MUST be performed only after IPsec processing is complete.

ip, security, ipsec

wire-format §3

IPv6 packets over Frame Relay are encapsulated using the NLPID frame format per [ENCAPS]. The NLPID value for IPv6 is 0x8E, placed after the Q.922 address and UI control byte (0x03). The Q.922 address is 2 or 4 octets in length.

ip

wire-format §6

The DLCI Format ND option has Type (1=source, 2=target), Length=1 (8 octets total), a 2-octet address-type field with both leading bits set to 1 and remaining bits zeroed, followed by the Q.922-encoded DLCI (10, 17, or 23 bits) zero-padded to fill the remaining 6 octets.

ip

wire-format §6

The Frame Relay Address Format ND option encodes an E.164, X.121, or NSAP address. The first address-value octet carries address-type bits (01), a 6-bit size field, followed by a 2-octet Address Family Number, then the BCD-encoded E.164/X.121 or binary NSAP address, zero-padded to an 8-octet boundary. Length is 2, 3, or 4 (for addresses up to 11, 19, or maximum NSAP octets, respectively).

ip

wire-format §5

The IPv6 link-local address for a Frame Relay interface is formed by appending the 64-bit Frame Relay interface identifier to the prefix FE80::/64, yielding a 128-bit address with the standard 10-bit link-local prefix followed by 54 zero bits and the interface identifier.

ip

wire-format §3

The Q.922 address encodes a DLCI in canonical (least-significant-bit-first) order. Three DLCI sizes are defined: 10 bits (2-octet Q.922), 17 bits (4-octet Q.922), and 23 bits (4-octet Q.922), distinguished by specific bit patterns in the address octets.

ip