Appendix A

Link-Layer Support for IPv6

This appendix describes the link-layer encapsulation for IPv6 packets for common LAN and WAN technologies and how IPv6 packets are encapsulated when sent across an IPv4 infrastructure.

Basic Structure of IPv6 Packets

On LAN and WAN media, IPv6 packets exist as link-layer frames. Figure A-1 shows the basic structure of IPv6 packets sent over LAN and WAN media.

Figure A-1. Basic structure of IPv6 packets sent on LAN and WAN media

The structure of IPv6 packets sent on LAN and WAN media consists of:

A link-layer header and trailer
The encapsulation placed on the IPv6 packet at the link layer is composed of a link-layer header and trailer.
An IPv6 header
This is the new IPv6 header. For more information, see Chapter 4, "The IPv6 Header."
Payload
The payload of the IPv6 packet includes zero or more IPv6 extension headers and the upper layer PDU. For more information, see Chapter 4, "The IPv6 Header."

LAN Media

To successfully troubleshoot IPv6 problems on a LAN, it is important to understand LAN encapsulations. LAN technologies encompass desktop technologies such as Ethernet, Token Ring, and FDDI. In some technologies (such as Ethernet), multiple encapsulations may exist. In each of these technologies, the IPv6 packet needs to be delimited, addressed, and identified as an IPv6 packet.

Current RFCs exist for sending IPv6 packets over the following LAN media:

Ethernet (RFC 2464)
Token Ring (RFC 2470)
FDDI (RFC 2467)
ARCnet (RFC 2497)

ARCnet is not discussed in this appendix. For more information about ARCnet encapsulation of IPv6 packets, see RFC 2497.

The IPv6 protocol for the Windows .NET Server 2003 family and Windows XP supports only the sending and receiving of IPv6 packets over FDDI interfaces and any LAN interface that registers itself with the Network Device Interface Specification (NDIS) layer as an 802.3 media type. This media type includes Ethernet, IEEE 802.11 wireless, phone line, power line, and other technologies.

Ethernet: Ethernet II

When sent over an Ethernet network, IPv6 packets use either Ethernet II or IEEE 802.3 Sub-Network Access Protocol (SNAP) encapsulation. IPv6 encapsulation for Ethernet links is described in RFC 2464. Figure A-2 shows Ethernet II encapsulation of IPv6 packets.

Figure A-2. Ethernet II encapsulation of IPv6 packets

The fields in the Ethernet header and trailer are:

Preamble
The Preamble field is used to synchronize the receiver and indicate the start of the Ethernet frame. The size of this field is 64 bits.
Destination Address
The Destination Address field contains the MAC address of the destination Ethernet node. The size of this field is 48 bits.
Source Address
The Source Address field contains the MAC address of the sending Ethernet node. The size of this field is 48 bits.
EtherType
The EtherType field indicates the upper layer protocol of the Ethernet payload. The size of this field is 16 bits. The EtherType field is set to 0x86DD for IPv6 packets. In contrast, the EtherType field is set to 0x800 for IPv4 packets.
Frame Check Sequence
The value of this field is a checksum that is used to check for bit-level errors in the Ethernet frame. The checksum value is computed by the sending Ethernet node and verified by the receiving Ethernet node. The size of this field is 32 bits.

IPv6 packets sent using Ethernet II encapsulation have a maximum size of 1,500 bytes and a minimum size of 46 bytes. IPv6 packets under 46 bytes in length are padded to 46 bytes to preserve the Ethernet minimum frame size of 64 bytes (not including the Preamble field).

Network Monitor Capture

Here is an example of Ethernet II encapsulation as displayed by Network Monitor (capture AppA_01 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

 + Frame: Base frame properties   ETHERNET: ETYPE = IPv6       ETHERNET: Destination address : 3333FF52F9D8           ETHERNET: .......1 = Group address           ETHERNET: ......1. = Locally administered address       ETHERNET: Source address : 00B0D0234733           ETHERNET: ......0. = Universally administered address       ETHERNET: Frame Length : 86 (0x0056)       ETHERNET: Ethernet Type : 0x86DD       ETHERNET: Ethernet Data: Number of data bytes remaining =
                                     72 (0x0048) + IP6: Hop Opts; Proto = ICMP6; Len = 24 + ICMP6: Group Membership Report

Notice that Network Monitor does not display the Preamble and Frame Check Sequence fields.

Ethernet: IEEE 802.3 SNAP

The IEEE 802.3 SNAP encapsulation uses a SNAP header to encapsulate the IPv6 packet so that it can be sent on an IEEE 802.3-compliant network. IEEE 802.3 SNAP encapsulation consists of an IEEE 802.3 header, an IEEE 802.2 Logical Link Control (LLC) header, a SNAP header, and an IEEE 802.3 trailer. Figure A-3 shows Ethernet IEEE 802.3 SNAP encapsulation of IPv6 packets.

Figure A-3. Ethernet IEEE 802.3 SNAP encapsulation of IPv6 packets

The fields in the IEEE 802.3 SNAP encapsulation are:

Preamble
The Preamble field is used to synchronize the receiver. The size of this field is 56 bits.
Start Delimiter
The Start Delimiter field indicates the start of the Ethernet frame. The size of this field is 8 bits.
Destination Address
The Destination Address field contains the MAC address of the destination Ethernet node. The size of this field is 48 bits.
Source Address
The Source Address field contains the MAC address of the sending Ethernet node. The size of this field is 48 bits.
Length
The Length field specifies the number of bytes in the IEEE 802.3 payload. This includes the IEEE 802.2 header and the SNAP header. The size of this field is 16 bits.
Destination Service Access Point (DSAP)
The DSAP field indicates the upper layer protocol of the payload for the destination. For SNAP-encapsulated payloads, the DSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
Source Service Access Point (SSAP)
The SSAP field indicates the upper layer protocol of the payload for the sender. For SNAP-encapsulated payloads, the SSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
Control
For SNAP-encapsulated payloads, the Control field is set to the defined value of 0x3, indicating that the 802.2 frame is an unnumbered frame. The size of this field is 8 bits.
Organization Code
The Organization Code field indicates the ID of the organization that defines the values in the two-byte field that follows the Organization Code field. For SNAP encapsulation, the Organization Code field is set to 0, indicating the IETF, who administers the values of the EtherType field. The size of this field is 24 bits.
EtherType
The EtherType field indicates the upper layer protocol of the payload. The size of this field is 16 bits. The EtherType field is set to 0x86DD for IPv6 packets.
Frame Check Sequence
The value of this field is a checksum that is used to check for bit-level errors in the Ethernet frame. The checksum value is computed by the sending Ethernet node and verified by the receiving Ethernet node. The size of this field is 32 bits.

IPv6 packets sent using an IEEE 802.3 SNAP frame have a maximum size of 1,492 bytes and a minimum size of 38 bytes. IPv6 packets under 38 bytes in length are padded to 38 bytes to preserve the Ethernet minimum frame size of 64 bytes (not including the Preamble and Start Delimiter fields).

Token Ring: IEEE 802.5 SNAP

When sent over a Token Ring network, IPv6 packets use the IEEE 802.5 SNAP encapsulation. IPv6 encapsulation for Token Ring links is described in RFC 2470. Figure A-4 shows IEEE 802.5 SNAP encapsulation of IPv6 packets.

Figure A-4. IEEE 802.5 SNAP encapsulation of IPv6 packets

The fields in the Token Ring encapsulation are:

Starting Delimiter
The Starting Delimiter field indicates the start of the Token Ring frame. The size of this field is 8 bits.
Access Control
The Access Control field indicates the frame type (token or data frame), the frame's priority, the frame's reservation level, and whether the frame has passed the ring monitor station. The size of this field is 8 bits.
Frame Control
The Frame Control field indicates whether the frame is a data frame or a Token Ring management frame and if a Token Ring management frame, the specific type. The size of this field is 8 bits.
Destination Address
The Destination Address field contains the MAC address of the destination Token Ring node. The size of this field is 48 bits.
Source Address
The Source Address field contains the MAC address of the sending Token Ring node. The size of this field is 48 bits.
DSAP
The DSAP field indicates the upper layer protocol of the payload for the destination. For SNAP-encapsulated payloads, the DSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
SSAP
The SSAP field indicates the upper layer protocol of the payload for the sender. For SNAP-encapsulated payloads, the SSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
Control
For SNAP-encapsulated payloads, the Control field is set to the defined value of 0x3, indicating that the 802.2 frame is an unnumbered frame. The size of this field is 8 bits.
Organization Code
The Organization Code field indicates the ID of the organization that defines the values in the two-byte field that follows the Organization Code field. For SNAP encapsulation, the Organization Code field is set to 0, indicating the IETF, who administers the values of the EtherType field. The size of this field is 24 bits.
EtherType
The EtherType field indicates the upper layer protocol of the payload. The size of this field is 16 bits. The EtherType field is set to 0x86DD for IPv6 packets.
Frame Check Sequence
The value of this field is a checksum that is used to check for bit-level errors in the Token Ring frame. The checksum value is computed by the sending Token Ring node and verified by the receiving Token Ring node. The size of this field is 32 bits.
Ending Delimiter
The Ending Delimiter field indicates the end of the Token Ring frame. The size of this field is 8 bits.
Frame Status
The Frame Status field indicates whether or not the destination address was recognized and whether or not the frame was copied. The size of this field is 8 bits.

IPv6 packets sent using Token Ring have a variety of MTUs depending on the maximum amount of time that a token ring node can hold the token, which can vary based on the data rate and the number of nodes on the ring. For more information, see RFC 2470.

FDDI

FDDI also uses the SNAP encapsulation. IPv6 encapsulation for FDDI links is described in RFC 2467. Figure A-5 shows FDDI encapsulation of IPv6 packets.

Figure A-5. FDDI encapsulation of IPv6 packets

The fields in the FDDI encapsulation are:

Preamble
The Preamble field is used to synchronize the receiver. The size of this field is 16 bits.
Starting Delimiter
The Starting Delimiter field indicates the start of the FDDI frame. The size of this field is 8 bits.
Frame Control
The Frame Control field indicates the frame class, the size of the source and destination addresses, and the frame type (token or data frame). The size of this field is 8 bits.
Destination Address
The Destination Address field contains the MAC address of the destination FDDI node. The size of this field is 48 bits.
Source Address
The Source Address field contains the MAC address of the sending FDDI node. The size of this field is 48 bits.
DSAP
The DSAP field indicates the upper layer protocol of the payload for the destination. For SNAP-encapsulated payloads, the DSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
SSAP
The SSAP field indicates the upper layer protocol of the payload for the sender. For SNAP-encapsulated payloads, the SSAP is set to the defined value of 0xAA. The size of this field is 8 bits.
Control
For SNAP-encapsulated payloads, the Control field is set to the defined value of 0x3, indicating that the 802.2 frame is an unnumbered frame. The size of this field is 8 bits.
Organization Code
The Organization Code field indicates the ID of the organization that defines the values in the two-byte field that follows the Organization Code field. For SNAP encapsulation, the Organization Code field is set to 0, indicating the IETF, who administers the values of the EtherType field. The size of this field is 24 bits.
EtherType
The EtherType field indicates the upper layer protocol of the payload. The size of this field is 16 bits. The EtherType field is set to 0x86DD for IPv6 packets.
Frame Check Sequence
The value of this field is a checksum that is used to check for bit-level errors in the FDDI frame. The checksum value is computed by the sending FDDI node and verified by the receiving FDDI node. The size of this field is 32 bits.
Ending Delimiter
The Ending Delimiter field indicates the end of the FDDI frame. The size of this field is 8 bits.
Frame Status
The Frame Status field indicates whether or not the destination address was recognized, whether or not the frame was copied, and whether or not the Frame Check Sequence field is valid. The size of this field is 16 bits.

FDDI allows an MTU of 4,352 bytes for IPv6 packets. The IPv6 MTU is derived from the 4,500 byte maximum payload for FDDI, less 22 bytes for FDDI MAC overhead, 8 bytes for the SNAP header, and 118 bytes that are reserved for future MAC header uses. All IPv6 packets are transmitted as asynchronous LLC frames using unrestricted tokens.

WAN Media

To successfully troubleshoot IPv6 problems in a wide area network, it is important to understand WAN encapsulations. WAN technologies encompass point-to-point technologies (for example, analog phone lines, Integrated Services Digital Network (ISDN), T-Carrier, and Switched-56) and packet switched technologies (for example, X.25, Frame Relay, and ATM). In each of these technologies, the packet needs to be delimited, addressed, and identified as an IPv6 packet.

Current RFCs exist for sending IPv6 packets over the following WAN media:

PPP (RFC 2472)
X.25 (RFC 1356)
Frame Relay (RFC 2590)
ATM (RFC 2492)

There is no specific RFC for IPv6 packets over an X.25 link; however, RFC 1356 describes how any packet is sent over an X.25 link.

The IPv6 protocol for the Windows .NET Server 2003 family and Windows XP does not support the sending and receiving of IPv6 packets over any WAN media. However, IPv6 packets encapsulated with an IPv4 header can be sent over any WAN media that supports IPv4 packets.

PPP

PPP, described in RFC 1661, is a standardized serial line encapsulation method that can be used over asynchronous serial lines, such as analog phone lines, and synchronous serial lines, such as T-Carrier, ISDN, or Synchronous Optical Network (SONET). PPP is a family of protocols that describe:

A multi-protocol encapsulation method.
A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. RFC 2472 describes the IPv6 Control Protocol (IPv6CP), which is the NCP for configuring the IPv6 protocol over a PPP link.

Only the encapsulation method is described here.

PPP encapsulation uses a variant of the ISO High Level Data Link Control (HDLC) protocol as described in RFC 1662. IPv6 encapsulation for PPP links is described in RFC 2472. Figure A-6 shows PPP encapsulation of IPv6 packets.

Figure A-6. PPP with HDLC framing encapsulation of IPv6 packets

The fields in the PPP header and trailer are:

Flag
The Flag field indicates the start and end of a PPP frame and is set to 0x7E. In consecutive PPP frames, only a single Flag character is used to mark both the end of a PPP frame and the beginning of the next PPP frame. The size of this field is 8 bits.
Address
The Address field is used in HDLC environments to address the frame to a destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, which is the broadcast address. The size of this field is 8 bits. Typically, the use of this field is suppressed.
Control
The Control field is used in HDLC environments for data-link layer sequencing and acknowledgments. For PPP, the Control field is set to 0x3 to indicate an unnumbered information (UI) frame. The size of this field is 8 bits. Typically, the use of this field is suppressed.
Protocol
The Protocol field identifies the protocol of the PPP payload. The Protocol field is set to 0x57 to indicate an IPv6 packet. In contrast, the Protocol field is set to 0x21 to indicate an IPv4 packet. The size of this field is 16 bits. Although defined as a 16-bit field, typically the Protocol field size is compressed to 8 bits.
Frame Check Sequence
The Frame Check Sequence field stores a checksum value that is used to check for bit-level errors in the PPP frame. The size of this field is 16 bits.

The MTU for a PPP connection (called the MRU, or Maximum Receive Unit) is negotiated by using LCP. The default MRU is 1,500 octets. If negotiated lower, a PPP host must still have the ability to receive 1,500-octet frames in the case of link synchronization failure.

The IPv6 protocol for the Windows .NET Server 2003 family and Windows XP does not support RFC 2472. Because PPP is not supported, IPv6 packets over PPTP and L2TP links are also not supported. However, IPv6 traffic can be sent over a PPP link if it is encapsulated with an IPv4 header using the coexistence technologies described in Chapter 11, "Coexistence and Migration."

X.25

X.25 was developed in the 1970s to provide dumb terminals with WAN connectivity across public data networks (PDNs). However, because of its flexibility and reliability, X.25 has emerged as an international standard for sending data across PDNs.

X.25 is a connection-oriented interface to a packet switched network (PSN) and provides error checking with guaranteed delivery of packets over the PSN by using either switched virtual circuits (SVCs) or permanent virtual circuits (PVCs). Because of its reliability and guaranteed delivery, X.25 works effectively for applications that require reliable transmission.

A router can connect via a Packet Assembler/Disassembler (PAD) to the X.25 network. The PAD is responsible for breaking down messages into packets and addressing them appropriately. The connection between the router and the PAD, the operations at the PAD, and the connection from the PAD to the carrier office is defined by the X.28, X.3, and X.29 specifications.

The X.25 specification maps to layers 1 through 3 of the OSI model. However, the X.25 specification was developed before the OSI model, so layer names are slightly different. The Physical layer is called X.21 and specifies the electrical and physical interface. The Data Link Layer is the Link Access Procedure-Balanced (LAPB) protocol, which takes care of frame composition, flow control, and error checking at the Link Access layer. The Packet layer corresponds to the Network layer and is responsible for the set up and addressing of the virtual circuit.

When IPv6 packets are encapsulated for transmission on X.25 networks, they are wrapped with two sets of headers that correspond to the X.25 Network and Data Link layers. The X.25 Network layer uses the Packet Layer Protocol (PLP). The X.25 Data Link layer uses LAPB, which is the same HDLC format as PPP.

Figure A-7 shows X.25 encapsulation of IPv6 packets.

Figure A-7. X.25 encapsulation of IPv6 packets

The fields in the PLP header are:

General Format Indicator
The General Format Indicator (GFI) indicates X.25 control information. The size of this field is 4 bits.
Logical Channel Number
The Logical Channel Number (LCN) field indicates the virtual circuit over which the packet is sent. When an X.25 virtual circuit is created, an X.25 LCN is assigned to that virtual circuit so that data can be addressed to the proper destination. The size of this field is 12 bits, allowing a maximum of 4,095 simultaneous connections (LCN 0 is used for X.25 signaling).
Packet Type Identifier
The Packet Type Identifier field indicates the type of X.25 packet (X.25 signaling messages vs. X.25 user data). The size of this field is 8 bits.

The fields in the LAPB header and trailer are:

Flag
The Flag field indicates the start and end of the X.25 frame and is fixed at 0x7E. The size of this field is 8 bits.
Address
The Address field is used to specify X.25 commands and responses. The size of this field is 8 bits.
Control
The Control field is used to indicate sequencing and acknowledgments for reliable data transfer. The size of this field is 8 bits.
Frame Check Sequence
The value of this field is a checksum used to check for bit-level errors in the LAPB frame. The size of this field is 16 bits.

To identify the X.25 payload being encapsulated, X.25 packets use the Network Layer Protocol Identifier (NLPID) field. The size of this field is 8 bits. For IPv6 packets, the NLPID is set to 0x8E. For IPv4 packets, the NLPID is set to 0xCC.

IPv6 packets sent over X.25 links have a default MTU size of 1,280 bytes, unless negotiated higher by the sender and receiver. Most X.25 networks have a maximum X.25 packet size of 256 or 512 bytes. In this case, X.25 fragmentation is used to send the 1,280-byte IPv6 packets across the X.25 network.

Frame Relay

Frame Relay was originally conceived as a protocol for use over ISDN interfaces. Because Frame Relay could be applied outside the realm of ISDN, it was developed as an independent protocol. Frame Relay is a Data Link layer protocol that is much faster than X.25 because it is more streamlined and does not provide error correction and flow control.

Within the Frame Relay PDN, Frame Relay switching implements statistical multiplexing instead of time division multiplexing. With statistical multiplexing, circuits can be used from devices that are not currently using their allocated circuits. This makes real-time networks that are "bursty" in nature ideal candidates for Frame Relay.

The Local Management Interface (LMI) manages the link. LMI is responsible for establishing a link and monitoring PVCs. Because modern digital links are less susceptible to errors, Frame Relay employs only a checksum to detect a corrupted frame and does not include an error correction mechanism. Frame Relay also relies on upper protocols for flow control over the link.

IPv6 packets sent over a Frame Relay network are encapsulated in a header and trailer that are also derived from the ISO HDLC protocol and has a similar structure to the PPP encapsulation. IPv6 packet behavior and encapsulation for Frame Relay links is described in RFCs 2491 and 2590. Figure A-8 shows Frame Relay encapsulation of IPv6 packets.

Figure A-8. Frame Relay encapsulation of IPv6 packets

The fields in the Frame Relay header and trailer are:

Flag
The Flag field indicates the start and end of the Frame Relay frame and is fixed at 0x7E. The size of this field is 8 bits.
Address
The Address field contains both the Data Link Connection Identifier (DLCI) that identifies the virtual circuit over which the frame is sent and congestion flags. Frame Relay standards allow for an Address field of variable size, but most implementations use a size of 16 bits.
Control
The Control field is set to 0x3 to indicate a UI frame. The size of this field is 8 bits.
Frame Check Sequence
The Frame Check Sequence (FCS) field stores a checksum value that is used to check for bit-level errors in the Frame Relay frame. The size of this field is 16 bits.

Like X.25, Frame Relay uses the NLPID field to identify the encapsulated payload. For IPv6 packets, the NLPID is set to 0x8E. For IPv4 packets, the NLPID is set to 0xCC.

MTUs for Frame Relay links vary according to the Frame Relay provider. As specified in RFC 2590, Frame Relay links have a maximum frame size of at least 1,600 bytes. Therefore, the default IPv6 MTU for Frame Relay links that use a 16-bit Address field is 1,592.

ATM: Null Encapsulation

ATM technology is based on the development of Broadband Integrated Services Digital Network (B-ISDN) for the high-speed transfer of voice, video, and data through PDNs. ATM is a connection-oriented non-guaranteed delivery service. ATM scales very well to LANs and WANs and can be used in a private network as well as a public data network.

ATM is different from Frame Relay in that, instead of sending messages that have frames of variable size, all messages are segmented and sent as equally sized cells. Each cell consists of a 5-byte header and a 48-byte payload. By making all messages the same size, switching is optimized and the need to buffer messages of varying sizes is eliminated. With these improvements, ATM is capable of reaching speeds from 64 kilobits per seconds (Kbps) to 9.6 gigabits per second (Gbps), depending upon the underlying physical layer.

Because it is an asynchronous mechanism, ATM differs from synchronous transfer mode methods, in which time-division multiplexing (TDM) techniques are employed to pre-assign devices to time slots. TDM is inefficient relative to ATM because with TDM the station can transmit only at a specified time, even though all the other time slots are empty. With ATM, a station can send cells whenever necessary.

Relative to IPv6, ATM functions as a link layer. ATM itself has its own set of layers that define:

How ATM cells are sent over several different physical mediums, such as SONET and Digital Service (DS)-3.
How connections are established and cells are passed through the ATM network.
How the data of higher level protocols, such as IPv4 and IPv6, are segmented and reassembled using 48-byte segments suitable for transmission over an ATM network. This layer is known as the ATM Adaptation layer.

IPv6 packets sent over an ATM network have an MTU of 9,180 bytes and are encapsulated by using ATM Adaptation Layer 5 (AAL5). AAL5 encapsulation consists of an AAL5 trailer added to the end of the IPv6 packet. The resulting data block (called the AAL5 PDU) is then segmented into 48-byte segments that become the payloads for 53-byte ATM cells.

IPv6 encapsulation for ATM links is described in RFC 2492. Figure A-9 shows ATM null encapsulation of IPv6 packets.

Figure A-9. ATM null encapsulation of IPv6 packets

The fields in the AAL5 trailer are:

Padding
The Padding field is added to the IPv6 packet so that the AAL5 PDU is an integral number of 48-byte segments. The size of this field varies from 0 to 47 bytes.
User to User Indication
The User to User Indication field is used to transfer information between AAL5 nodes. The size of this field is 8 bits.
Common Part Indicator
The Common Part Indicator field is used for alignment purposes so that the unpadded portion of the AAL5 trailer is on an 8-byte boundary. The size of this field is 8 bits.
Length of Payload
The Length of Payload field specifies the length in bytes of the IPv6 packet so that the receiver can discard the Padding field. The size of this field is 16 bits.
Frame Check Sequence
The Frame Check Sequence field stores a checksum value that is used to check for bit-level errors in the AAL5 PDU. The size of this field is 32 bits. AAL5 uses the same CRC-32 algorithm as 802.x networks such as Ethernet and Token Ring.

Before being sent on the ATM network, the AAL5 PDU is segmented by the ATM Segmentation and Reassembly (SAR) sublayer into 48-byte units. These units become the ATM payloads for a stream of ATM cells. When the last48-byte segment is sent, a bit in the Payload Type field of the ATM header is set to 1 to indicate the last cell in the AAL5 PDU.

When the last cell is received, the receiver uses the Frame Check Sequence field to check the validity of the bits in the AAL5 PDU. The receiver then uses the Length of Payload field to discard any padding. The AAL5 trailer is stripped and the originally transmitted IPv6 packet is then passed to the IPv6 protocol for processing. If a single ATM cell for the AAL5 PDU is dropped from the network, the entire IPv6 packet must be resent.

ATM: SNAP Encapsulation

The ATM null encapsulation can be used when only the IPv6 protocol is operating over a given ATM virtual circuit. Multiple protocols operating over the same ATM virtual circuit require a protocol identifier so that the receiver can determine the protocol being sent and pass the resulting data to the appropriate protocol parsing or routing routine. This capability is especially important for multiprotocol routers.

To add a protocol identifier to the AAL5 PDU, an IEEE 802.x SNAP header is added. It contains the EtherType (set to 0x86DD) that identifies the payload as an IPv6 packet. As part of the virtual channel connection (VCC) negotiation process between two ATM endpoints, an agreement is reached on whether a single protocol is to be used (in which case the SNAP header is not required) or multiple protocols are to be used (in which case a SNAP header is required).

Figure A-10 shows ATM SNAP encapsulation of IPv6 packets.

Figure A-10. ATM SNAP encapsulation of IPv6 packets

IPv6 over IPv4

IPv6 over IPv4 tunneling is the encapsulation of IPv6 packets with an IPv4 header so that IPv6 packets can be sent over an IPv4 infrastructure. Figure A-11 shows IPv4 encapsulation of IPv6 packets.

Figure A-11. IPv4 encapsulation of IPv6 packets

Within the IPv4 header:

The IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet.
The Source and Destination fields are set to the IPv4 addresses of the tunnel endpoints. The tunnel endpoints are either manually configured as part of the tunnel interface or are determined from the IPv4 address of the sending interface and the next-hop address of the destination address in the IPv6 header.

For IPv6 over IPv4 tunneling, the IPv6 path MTU for the destination is typically 20 less than the IPv4 path MTU for the destination (to a minimum of 1,280 bytes between the tunnel endpoints). However, if the IPv4 path MTU is not stored for each tunnel, there are instances in which the IPv4 packet will need to be fragmented at an intermediate router. In this case, the IPv6 over IPv4 tunneled packet must be sent with the Don't Fragment flag in the IPv4 header set to 0.

References

RFC 1356 - "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode"

RFC 1661 - "The Point to Point Protocol (PPP)"

RFC 1662 - "PPP in HDLC-like Framing"

RFC 2464 - "Transmission of IPv6 Packets over Ethernet Networks"

RFC 2467 - "Transmission of IPv6 Packets over FDDI Networks"

RFC 2470 - "Transmission of IPv6 Packets over Token Ring Networks"

RFC 2472 - "IP Version 6 over PPP"

RFC 2491 - "IPv6 over Non-Broadcast Multiple Access (NBMA) Networks"

RFC 2492 - "IPv6 over ATM Networks"

RFC 2497 - "Transmission of IPv6 Packets over ARCnet Networks"

RFC 2590 - "Transmission of IPv6 Packets over Frame Relay Networks Specification"

Appendix A -- Link-Layer Support for IPv6